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ABSTRACT 


The  Navy  has  developed  Distance  Support  tools  to  support  specific  naval  systems.  These 
tools  often  do  not  facilitate  knowledge  retention  and  reutilization;  to  resolve  this  problem, 
a  Data  Aggregation  System  (DAS)  was  recommended  to  aggregate  and  integrate  data  to 
improve  fleet  readiness.  A  systems  engineering  (SE)  process,  derived  from  the  2009 
Department  of  Defense  (DoD)  SE  Model,  was  used  to  develop  the  DAS.  Based  on  past 
Navy  lead  Distance  Support  studies  and  completed  surveys,  the  team  determined  the 
stakeholders  needed  a  data  aggregation  system  that  provides  1)  easily  accessible  data, 
2)  high  quality  information,  3)  current  data,  4)  well  organized  information,  and 
5)  information  reported  on  demand.  The  team  conducted  requirements  analysis  to  trace 
and  prioritize  the  system  requirements  to  stakeholders’  needs.  The  requirements  were 
then  mapped  to  functions.  The  high  level  system  functions  identified  were  1)  obtain  data, 
2)  process  data,  3)  analyze  data,  4)  report  data,  and  5)  display  data.  An  analysis  of 
Alternatives  (AoA)  using  gap  analysis  yielded  two  feasible  solutions,  1)  modify  the 
Engineering  and  Supportability  Decision  System  (ESDS)  and  2)  develop  a  new  system. 
The  results  of  cost  and  risk  recommended  the  modified  ESDS  solution.  The  solution 
architecture  was  documented  using  Vitech’s  CORE®  software  suite. 
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EXECUTIVE  SUMMARY 


The  Navy  has  developed  several  Distance  Support  tools  to  support  specific  naval 
systems.  These  tools  often  do  not  facilitate  knowledge  retention  and  reutilization.  A  Data 
Aggregation  System  (DAS)  was  proposed  to  aggregate  and  integrate  data  as  well  as  to 
capture  knowledge  to  improve  fleet  readiness.  The  team’s  recommendation  is  to 
implement  a  Data  Aggregation  System  (DAS)  which  modifies  the  existing  Engineering 
and  Supportability  Decision  System  (ESDS),  to  retain  technical  and  supportability  data  as 
well  as  aggregate  and  integrate  information  in  a  timely  manner. 

This  report  describes  the  requirements  and  parameters  necessary  to  provide  a 
technically  feasible,  cost  effective,  and  efficient  solution  that  Naval  Surface  Warfare 
Center,  Port  Hueneme  Division  (NSWC  PHD)  can  further  develop  to  provide  Distance 
Support  to  the  United  States  Navy  (USN).  Distance  Support  is  defined  by  the  Chief  of 
Naval  Operations  (CNO)  as  “a  Navy  Enterprise  effort  that  combines  people,  processes, 
and  technology  into  a  collaborative  infrastructure  without  regard  to  geographic  location” 
(CNO  2007,  2).  Specifically  for  NSWC  PHD,  Distance  Support  is  the  technical  help 
provided  remotely  to  USN  ships  in  all  areas  of  operation  and  maintenance  for  warfare 
systems. 

The  team  developed  the  following  problem  statement  to  more  completely  capture 
the  issue. 

In  recent  years,  the  Navy’s  decision  to  reduce  manning  and  training  with 
the  increased  complexity  of  combat  systems  as  new  programs  emerge 
have  led  to  a  decline  in  Sailors’  ability  to  operate,  maintain,  and  sustain 
combat  systems  to  the  levels  required  to  meet  mission  readiness 
requirements  (Balisle  2011).  Numerous  Distance  Support  tools  currently 
used  to  respond  to  USN  fleet  combat  system  issues  are  often  slow  and 
ineffective.  The  eventual  technical  solutions  are  often  not  captured  for 
knowledge  retention  and  reutilization,  nor  are  they  available  as  a  self-help 
tool  for  the  war-fighters.  Knowledge  data  that  is  captured  is  difficult  to 
access  and  utilize  in  a  timely  manner.  In  addition,  current  Distance 
Support  tools  used  by  Subject  Matter  Experts  (SME)  to  obtain  and  analyze 
system  performance  metrics  are  manually  intensive  and  limited  in 
capability. 
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A  systems  engineering  (SE)  approach,  adapted  from  the  2009  Department  of 
Defense  (DoD)  SE  Model,  was  developed  and  followed  to  ensure  the  recommended  DAS 
satisfied  stakeholders’  needs.  The  first  step  of  the  SE  process  was  to  define  stakeholder 
needs.  Past  NSWC  PHD  Distance  Support  studies  and  already  completed  surveys  were 
analyzed  to  identify  needs  associated  with  DAS.  It  was  determined  that  the  stakeholders 
need  a  system  that  provides  1)  easily  accessible  data,  2)  high  quality  information, 
3)  current  data,  4)  well  organized  information,  and  5)  information  displayed  and  reported 
when  needed.  An  operational  concept  diagram  was  developed  to  show,  at  a  very  high 
level,  the  operational  relationships  amongst  users  and  the  new  proposed  DAS.  This  was 
an  important  first  step  to  developing  a  conceptual  design  of  the  system  that  would 
provide  the  stakeholders  with  a  preferred  solution. 

The  second  step  in  the  SE  process  was  to  conduct  requirements  analysis  to 
translate  the  needs  of  the  stakeholders  into  DAS  requirements.  The  team  developed 
three  categories  of  requirements,  1)  characteristics,  2)  design  and  construction,  and 
3)  component  level  requirements.  Functional  analysis  was  then  conducted  to  identify  the 
system  resources  that  would  be  required  for  DAS  to  achieve  the  operational  concept  that 
was  developed  from  the  requirements  analysis.  The  high  level  functions  that  were 
determined  necessary  to  aggregate  data  were  1)  obtain  data,  2)  process  data,  3)  analyze 
data,  4)  report  data,  and  5)  display  data. 

The  team  conducted  an  Analysis  of  Alternatives  (AoA)  to  determine  the  best 
alternative  that  would  achieve  DAS  capabilities  and  meet  the  stakeholders’  needs.  Six 
alternatives  were  identified  and  analyzed  to  determine  the  two  most  effective  alternatives, 
1)  build  a  brand  new  system  or  2)  modify  and  improve  an  existing  system  to  meet  the 
needs  of  the  stakeholders.  To  determine  the  most  feasible  existing  system,  the  team 
defined  a  number  of  evaluation  measures  and  metrics,  such  as  1)  the  ability  to  access 
data,  with  a  Threshold  of  10  seconds  and  an  Objective  of  2  seconds,  or  2)  the  Mean  Time 
to  Repair  (MTTR),  with  a  Threshold  of  2  hours  and  an  Objective  of  1  hour.  The  team 
originally  identified  sixteen  systems  that  could  be  modified  to  meet  stakeholders’  needs. 
After  using  the  evaluation  metrics  to  assess  each  existing  system’s  performance  based  on 
their  current  capabilities,  the  team  narrowed  the  list  down  to  eight  potential  existing 
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systems.  Using  swing  weight  matrices  and  the  Quality  Function  Deployment  (QFD) 
House  of  Quality  (HOQ)  model,  the  team  further  reduced  the  list  to  four  potential 
existing  systems,  1)  ESDS,  2)  Aegis  Combat  System  Reliability  Maintainability  and 
Supportability  Database  (ACSRMS),  3)  Maintenance  Figure  of  Merit  (MFOM),  and 
4)  Material  Readiness  Database  (MRDB).  A  gap  analysis  determined  that  the  existing 
system  with  the  least  amount  of  functional  gaps  was  ESDS.  Cost  Analysis  was  conducted 
using  Constructive  Systems  Engineering  Cost  Model  (COSYSMO)  to  compare  the  two 
alternatives,  1)  modify  ESDS  (termed  as  ESDS+)  or  2)  build  a  new  system.  The  results 
showed  that  ESDS+  would  cost  60%  less  than  building  a  new  system,  with  the  top  cost 
drivers  being  system  design  and  product  evaluation.  From  Risk  Analysis,  Expert 
COSYSMO  showed  that  ESDS+  had  less  risk  issues  than  building  a  new  system.  The 
major  risk  area  for  both  systems  was  attributed  to  two  factors,  documentation  and  the 
number  and  diversity  of  platforms.  Thus,  the  results  of  the  AoA  lead  the  team  to 
recommend  modifying  the  existing  ESDS,  rather  than  develop  a  whole  new  system 

The  third  and  final  step  in  the  SE  process  was  to  develop  the  system  architecture 
for  DAS  and  ESDS+.  After  defining  DAS  requirements  and  tracing  them  to  the  system 
functions,  the  team  identified  all  of  the  relationships  between  the  functions  and 
components  and  entered  them  into  Vitech’s  CORE®  software  suite  to  document  the 
functional  architecture.  The  team  used  Integration  Definition  for  Function  Modeling 
(IDEFO)  to  model  both  the  functional  and  physical  architectures  of  DAS.  The  team  also 
used  a  number  of  DoD  Architecture  Framework  (DoDAF)  products  to  identify  the  tasks, 
activities  and  operational  elements  required  to  complete  the  DAS’  mission,  and  to  depict 
the  interconnections  required  for  DAS  to  function.  The  architecture  for  ESDS+  was  then 
developed  based  on  the  gap  analysis  and  documented  using  DODAF  products  and  IDEFO 
models.  By  developing  the  system  architecture,  the  team  was  able  to  apply  a  SE  approach 
toward  solving  a  real  world  problem  for  the  Navy  utilizing  the  knowledge  and  skills 
acquired  from  the  NPS  MSSE  curriculum.  The  SE  process  proved  to  be  effective  at 
facilitating  a  thorough  AoA  that  resulted  in  an  architecture  that  satisfies  the  stakeholder 
needs. 
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I. 


INTRODUCTION  AND  PROJECT  OVERVIEW 


This  capstone  report  has  been  developed  by  a  team  of  students  at  the  Naval 
Postgraduate  School  (NPS)  in  the  Master’s  of  Science  in  Systems  Engineering  (MSSE) 
Distance  Learning  Cohort  311-1130.  The  team,  all  employees  of  Naval  Surface  Warfare 
Center,  Port  Hueneme  Division  (NSWC  PHD),  followed  the  classic  “V”  model  of 
systems  engineering  (SE),  developed  by  Kevin  Forsberg  and  Hal  Mooz  (Forsberg,  Mooz, 
and  Cotterman  2005).  The  “V”  model  captured  succinctly  what  the  team  saw  as  a  logical 
path  for  developing  a  customer  validated  system  based  on  the  customer’s  needs.  The 
problem  was  decomposed  and  analyzed  so  a  solution  could  be  designed  that  will  be 
validated  and  verified  by  the  customer.  Past  NSWC  PHD  Distance  Support  studies  and 
already  completed  surveys  were  analyzed  to  develop  stakeholder  requirements,  upon 
which  functional  analysis  was  performed  using  the  Integration  Definition  for  Function 
Modeling  (IDEFO)  method  developed  in  CORE®  software  suite  and  applied  the 
Department  of  Defense  Architecture  Framework  (DoDAF)  to  develop  the  system 
architecture.  An  Analysis  of  Alternatives  (AoA)  was  performed  and  development  costs 
were  estimated.  Planning  for  solution  implementation,  integration  and  verification  and 
validation  were  completed  and  are  provided  in  a  section  listing  recommendations.  The 
conclusions  made  in  this  report  are  a  direct  result  of  the  team’s  education  and  experiences 
supporting  the  United  States  Navy  (USN)  and  its  Sailors,  the  research  and  analysis  of 
customers  and  their  needs,  and  aligns  with  the  Chief  of  Naval  Operations  (CNO)  Navy 
Distance  Support  Policy,  which  states  that  Distance  Support  is  to  be  the  “Fleet’s  principal 
web-based  readiness  enabler,  facilitating  timely  technical  assistance,  knowledge  and 
education  tools,  and  logistic  support”  (CNO  2007,  1). 

The  requirements  of  homeland  defense,  national  security,  and  the  war  on 
terrorism,  as  outlined  in  the  National  Strategy  for  Homeland  Security  dated  July  2002, 
have  made  a  Navy  ship’s  mission  more  critical  than  ever  (U.S.  Department  of  Homeland 
Security  2002).  When  equipment  fails  there  is  little  time  to  wait  for  engineers  or 
technicians  to  fly  to  the  deployed  ship  to  help  resolve  the  problem,  and  in  today’s  current 
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fiscal  climate,  there  is  a  strong  pressure  for  In  Service  Engineering  Agents  (ISEA),  which 
is  one  of  NSWC  PHD’s  main  responsibilities,  to  reduce  costs.  As  an  ISEA,  NSWC  PHD 
provides  support  through  installation,  certification  and  training  of  Sailors  to  operate  and 
maintain  surface  ship  combat  systems  and  weapon  systems  already  installed  aboard  ships. 
In  a  memorandum  from  the  Commander  of  Naval  Sea  Systems  Command  (NAVSEA)  on 
promoting  efficient  spending,  all  agencies  are  directed  to  take  more  aggressive  actions  to 
perform  mission  critical  functions  in  the  most  efficient  and  cost  effective  manner  (Vice 
Admiral  (VADM)  McCoy  2012).  Functional  areas,  such  as  the  use  of  government  funds 
for  travel,  are  directly  affected  and  as  a  result,  to  maintain  current  levels  of  support  while 
complying  with  a  reduction  of  travel,  it  is  imperative  that  effective  Distance  Support  tools 
are  offered  to  augment  the  support  of  those  engineers  and  to  provide  the  best  possible 
level  of  support  to  the  USN.  Distance  Support  is  defined  by  the  CNO  as  “a  Navy 
Enterprise  effort  that  combines  people,  processes,  and  technology  into  a  collaborative 
infrastructure  without  regard  to  geographic  location”  (CNO  2007,  2-1).  Specifically  for 
NSWC  PHD,  Distance  Support  is  the  technical  help  provided  remotely  to  USN  ships  in 
all  areas  of  operation  and  maintenance  for  warfare  systems. 

Through  the  development,  utilization,  and  delivery  of  leading-edge  Distance 
Support  technology  to  Sailors  at  sea,  the  engineers,  logisticians,  and  technicians  of 
NSWC  PHD  are  working  to  help  USN  ships  return  to  operational  readiness  twenty  four 
hours  a  day,  seven  days  a  week  without  having  to  leave  their  positions.  To  NSWC  PHD, 
Distance  Support  is  important  for  the  following  reasons: 

•  Reduced-manned  ships,  such  as  the  Littoral  Combat  Ship  (LCS)  can 
equate  to  a  smaller  skill  set  of  maintenance  expertise 

•  Increasing  complexity  of  systems  due  to  technological  advancements, 
integration  of  emergent  capabilities,  and  foreign  combat  system  elements 
makes  support  more  complicated 

•  Pressures  to  reduce  Total  Ownership  Costs  (TOC)  affect  the  amount  spent 
on  supportability. 
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Current  Distance  Support  solutions  performed  at  NSWC  PHD  include  remote 
monitoring,  prognostics  and  knowledge  management.  Remote  monitoring  utilizes 
satellite  links  to  evaluate  system  operation  aboard  ships.  Prognostics  is  done  when  data 
from  shipboard  tests  is  sent  to  NSWC  PHD  and  examined  for  warning  indications  and 
trends  that  can  lead  to  the  discovery  of  these  failed  parts.  Knowledge  management  is 
when  NSWC  PHD  releases  advisories,  workarounds  and  heuristics  of  trouble  calls  to  be 
stored  and  accessed  by  others.  Although  these  methods  are  sound,  they  are  often  slow  and 
ineffective.  Numerous  Distance  Support  tools  exist;  however,  they  were  independently 
developed  by  each  naval  system.  These  tools  each  have  their  own  unique  set  of 
requirements  and  capabilities  and  therefore  function  independently.  These  tools  can  be 
consolidated  and/or  integrated  to  more  effectively  provide  the  USN  with  a  more  capable 
Distance  Support  infrastructure.  In  addition,  Distance  Support  activities  are  often  not 
retained  for  knowledge  retention  and  reutilization.  Knowledge  that  is  captured  is  difficult 
to  access  and  utilize  in  a  timely  manner.  Better  tools  need  to  be  developed  to  allow 
knowledge  to  be  captured  and  made  ready  for  use  when  needed  to  help  improve  Distance 
Support  and  ultimately  fleet  readiness.  For  this  capstone  project,  the  team  focused  on 
determining  what  methods  and  tools  were  needed  to  allow  Distance  Support  knowledge 
and  experience  to  be  captured  and  accessed  efficiently. 

The  team  initially  performed  limited  benchmarking,  which  is  a  process  of 
investigating  and  discovering  how  others  perform  and/or  provide  particular  functions  and 
products  of  interest.  For  this  project,  the  team  researched  how  other  organizations 
conduct  Distance  Support,  whether  or  not  they  have  experienced  similar  problems,  and 
how  they  determine  if  Distance  Support  methods  are  successful.  It  was  found  that 
because  of  USN  mission  requirements,  system  failures  cannot  be  tolerated  for  prolonged 
periods,  which  means  the  operators  are  more  concerned  about  their  present  status,  not  in 
creating  a  holistic  Distance  Support  system. 

This  need  to  provide  immediate  support  has  created  an  environment  where  the 
reaction  of  technical  support  responders  is  to  focus  on  near  term  or  real  time  solutions 
because  their  primary  concern  is  for  ships  in  harm’s  way,  needing  fully  operational 
systems  to  avoid  compromising  their  mission  and  loss  of  life.  The  result  is  a  need  for  a 
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perpetually  running  system  with  the  highest  possible  operational  availability  and  lowest 
possible  total  downtime.  While  deployed,  there  are  no  spare  ships  to  support  a  critical 
mission  like  there  are  spare  tanks  on  the  ground  for  the  Army  or  aircraft  in  the  hangar  for 
the  Air  Force.  During  initial  research  and  discussions,  it  was  learned  that  the  Navy 
already  possesses  numerous  data  collection  and  knowledge  capturing  tools  and  databases, 
such  as  modernization  planning  databases,  casualty  reporting  databases,  and  specific 
system  technical  assist  forms.  Based  on  stakeholder  feedback,  the  collective  execution  of 
Distance  Support  was  unsatisfactory. 

A.  PROBLEM  STATEMENT 

In  a  2010  Aegis  Weapon  System  (AWS)/SPY  Radar  Readiness  Report,  the 
Deputy  Commander  of  Surface  Warfare  (SEA  21)  Rear  Admiral  James  McManamon 
noted  that  “A  decline  in  Sailors  ability  to  operate,  maintain,  and  sustain  (combat  systems) 
necessitates  the  need  to  optimize  Distance  Support  from  fleet  field  support  activities  to 
meet  current  and  future  fleet  readiness  demands.”  As  new  surface  ship  programs  emerge, 
the  complexity  of  combat  systems  has  increased.  In  recent  years,  the  Navy  has  identified 
reducing  manning  levels  as  a  key  approach  to  reduce  the  fleet’s  operational  costs.  In  a 
2011  report  detailing  a  review  panel  analysis  of  surface  force  readiness,  it  was  noted  that 
the  Navy’s  decision  to  reduce  manning  dropped  the  fleet’s  availability  levels  to  below  the 
levels  required  to  support  material  readiness  requirements  (Balisle  2011).  With  decreased 
manning,  and  the  problem  of  inadequate  Distance  Support,  problems  with  fleet  readiness 
compound:  reduced  manning  and  inefficient  Distance  Support  results  in  reduced  fleet 
readiness,  increases  shore  activity  and  Subject  Matter  Expert  (SME)  manpower 
requirements,  decreases  fleet  independence,  decreases  efficiencies,  and  increases  TOC. 

As  has  been  previously  noted,  current  NSWC  PHD  Distance  Support  systems  are 
often  slow  and  ineffective,  with  each  trouble  call  being  handled  on  an  ad  hoc  basis  and 
relying  heavily  on  the  servicing  engineer’s  personal  experience.  The  solutions  provided 
are  not  often  captured  for  knowledge  retention  and  reutilization  and  are  not  available  as  a 
self-help  tool  for  the  USN  fleet  as  most  responders  and  operators  are  more  concerned 
with  their  present  status  rather  than  the  health  of  the  holistic  Distance  Support  system. 
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Current  tools  used  by  the  NSWC  PHD  SMEs  to  obtain  and  analyze  system  performance 
metrics  are  manually  intensive,  where  operators  must  manually  record  and  provide  all 
performance  metrics  to  the  SMEs,  and  are  thus  limited  in  capability.  As  a  result, 
engineering  and  supportability  issues  are  not  addressed  in  a  timely  manner  and  NSWC 
PHD  SMEs  are  reacting  to  problems  after  they  occur  rather  than  being  proactive  to  try 
and  prevent  problems.  Furthermore,  establishing  relationships  between  similar  problems 
continues  to  be  a  challenge  as  there  is  no  systematic  method  to  capture  and  maintain 
corporate  knowledge  of  system  issues  found  by  the  SMEs.  A  user-friendly  efficient  tool 
does  not  exist  that  captures  knowledge  through  multiple  available  data  sources  for 
maintenance,  performance  and  logistics  that  could  be  utilized  in  a  timely  manner  to  make 
Distance  Support  a  more  responsive  and  effective  product. 

The  CNO  defines  Distance  Support  as  “a  Navy  Enterprise  effort  that  combines 
people,  processes,  and  technology  into  a  collaborative  infrastructure  without  regard  to 
geographic  location...  [and]  Distance  Support  projects  reactive,  proactive,  and  predictive 
support  to  Sailors  across  functional  areas  in  order  to  achieve  the  right  readiness  at  the 
right  time,  at  the  right  cost”  (CNO  2007,  2).  The  CNSF  categorizes  Distance  Support  by 
the  following  four  functional  areas: 

•  Logistics 

•  Maintenance  and  Modernization 

•  Manpower,  Personnel,  Training  and  Education  (MPT&E) 

•  War  fighting. 

In  addition,  each  of  these  four  categories  has  various  sub-functions  and  unique  processes. 
The  magnitude  and  volume  of  fleet  Distance  Support  activities  that  occur  across  these 
functional  areas  is  enormous.  The  chart  in  Figure  1  describes  some  of  the  overall 
activities  that  are  currently  involved  in  providing  Distance  Support  to  the  fleet. 
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Figure  1.  Distance  Support  Process 
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In  the  far  left  of  Figure  1,  the  fleet  customer’s  roles  and  needs  are  captured,  in  the  list  of 
requirements  that  are  needed  to  conduct  their  mission.  These  requirements  feed  into  the 
primary  functions  that  ship’s  personnel  perform,  which  include  maintenance,  logistics, 
training,  personnel  and  mission  readiness.  “Shore  Support,”  is  the  infrastructure  that 
possesses  the  knowledge  and  capabilities  that  the  fleet  needs  to  support  their  mission. 
Between  the  fleet  and  shore  support  is  the  transport  system  that  passes  information  and 
resources  to  and  from  the  ship.  As  the  diagram  shows,  Distance  Support  covers  many 
functions  and  is  quite  complex. 

The  team  soon  realized  that  a  capstone  project  that  improves  fleet  Distance 
Support  across  all  four  functional  areas  was  beyond  their  ability,  given  the  limited 
resources  and  time  constraints  to  complete  the  project.  The  team  agreed  that  the  project 
had  to  be  scoped  to  a  manageable  level,  so  it  was  re-focused  to  the  Distance  Support 
areas  that  NSWC  PHD  currently  supports.  NSWC  PHD  is  primarily  involved  in  limited 
aspects  of  logistics,  maintenance,  and  modernization  of  combat  systems  installed  on 
surface  ships.  Since  most  of  the  team’s  work  is  related  to  maintenance,  the  team  limited 
the  scope  of  the  research  effort  to  maintenance  functions.  NSWC  PHD’s  capabilities 
include  both  remote  systems  monitoring  and  technical  assistance.  Both  services  are 
provided  in  real  time,  near  real  time,  and  on  a  periodic  basis.  In  2011,  NSWC  PHD 
promulgated  a  Fleet  Support  Guidance  document,  where  remote  monitoring  was  defined 
as  “the  automated  collection  of  the  minimum  required  data  provides  the  greatest 
opportunity  to  ensure  the  fleet  is  ready  for  war”  and  technical  assistance  was  described  as 
an  act  that  “may  take  various  forms  of  two  way  contact  including  telephone,  e-mail,  web 
‘chat’,  streaming  video,  etc.” 

In  an  effort  to  limit  the  scope  of  the  project  and  increase  chances  for  success,  the 
team  solicited  input  from  NSWC  PHD  stakeholders.  Stakeholders  informed  the  team  that 
they  wanted  the  fleet’s  ability  to  help  itself  improved  and  to  improve  capturing  technical 
responses  to  technical  assistances.  This  guided  the  team’s  focus  to  developing  a  solution 
to  aggregate  data  from  numerous  existing  Distance  Support  sources  and  export  data  to  the 
fleet  to  promote  self-help  and  facilitate  trend/failure  analysis  opportunities.  Figure  2 
shows  how  data  will  flow  to  and  from  the  aggregation  tool. 
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Figure  2.  Distance  Support  Process  Focus  Area 


After  multiple  iterations  from  discussions  with  advisors  and  stakeholders,  the 
team  developed  the  following  problem  statement  to  more  completely  capture  the  issue  at 
hand. 


In  recent  years,  the  Navy’s  decision  to  reduce  manning  and  training  with 
the  increased  complexity  of  combat  systems  as  new  programs  emerge 
have  led  to  a  decline  in  Sailors’  ability  to  operate,  maintain,  and  sustain 
combat  systems  to  the  levels  required  to  meet  mission  readiness 
requirements  (Balisle  2011).  Numerous  Distance  Support  tools  currently 
used  to  respond  to  USN  fleet  combat  system  issues  are  often  slow  and 
ineffective.  The  eventual  technical  solutions  are  often  not  captured  for 
knowledge  retention  and  reutilization,  nor  are  they  available  as  a  self-help 
tool  for  the  war-fighters.  Knowledge  data  that  is  captured  is  difficult  to 
access  and  utilize  in  a  timely  manner.  In  addition,  current  Distance 
Support  tools  used  by  SMEs  to  obtain  and  analyze  system  performance 
metrics  are  manually  intensive  and  limited  in  capability. 

This  problem  statement  was  derived  based  on  two  previous  Distance  Support  studies  that 

concluded  that  Distance  Support  is  often  slow  and  ineffective.  These  studies  are  not 
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releasable  to  the  general  public  and  were  obtained  from  NSWC  PHD  sponsors.  The  first 
study  was  conducted  by  the  AWS/SPY  Radar  Readiness  Task  Force  in  October  of  2009. 
The  Task  Force  performed  an  intensive  review  of  all  aspects  regarding  AWS/SPY  to 
determine  the  factors  that  affect  readiness  for  these  two  key  warfare  systems  of  the  USN 
Fleet.  The  results  and  recommendations  clearly  pointed  to  these  factors  negatively 
affecting  readiness.  Some  of  the  key  issues  identified  are  as  follows: 

•  Manpower  reductions  and  a  lack  of  necessary  experience  in  operators 

•  Inadequate  shore-based  training  for  the  operators  prior  to  deployment 

•  Electronic  versions  of  system  drawings  are  being  supplied  to  ships  to  save 
expense,  but  they  are  difficult  to  use  in  troubleshooting 

•  Spare  parts  are  not  available  on-board;  requisitions  have  to  be  filled  from 
other  locations 

•  Uncertainty  of  who  to  contact  for  Distance  Support  and  on-site  technical 
support  and  inefficiencies  when  support  is  provided 

•  Auxiliary  equipment  support  test  and  maintenance  is  frequently 
unavailable 

•  Preventative  maintenance  is  not  emphasized 

•  Fewer  periodic  ship  assessments  for  the  systems  are  performed  than 
recommended 

•  Distance  Support  is  not  used  as  often  as  it  should 

•  System  performance  monitoring  and  data  collection  is  not  being 
adequately  done  to  determine  readiness 

•  There  is  not  a  consistent  method  to  document  issues  (2010  AWS/SPY 
Radar  Readiness  Report) 

The  second  study  used  was  the  Distance  Support  Capability  Based  Assessment 
(CBA),  which  was  conducted  under  the  authority  of  Deputy  Commander,  United  States 
Fleet  Forces  Command  (USFFC)  as  part  of  a  Distance  Support  Functional  Analysis 
performed  in  2010.  The  Distance  Support  CBA  produced  an  integrated  Distance  Support 
capability  proposal  following  the  Joint  Doctrine,  Organization,  Training,  Materiel, 
Leadership  and  Education,  Personnel  and  Facilities  (DOTMLPF)  and  policy  solutions. 
The  CBA  fulfilled  the  analysis  portion  of  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS).  It  defined  Distance  Support  capability  needs,  capability 
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gaps,  capability  excesses,  and  approaches  to  provide  those  capabilities  within  a  specified 
functional  or  operational  area.  The  Distance  Support  CBA  has  identified  several  areas 
that  need  to  be  improved.  Those  that  directly  apply  to  this  capstone  project  are 
summarized  as  follows: 

•  Knowledge  Management-Distance  Support  needs  to  be  focused  on 
enabling  information  sharing  and  providing  remote  support  for 
maintenance  and  logistics.  If  effective,  the  burden  on  the  shore-based 
infrastructure  will  be  lessened. 

•  Collaborative  Environment-Distance  Support  needs  to  utilize 

collaboration  to  provide  timely  technical  responses,  predict  future  material 
concerns  and  to  enable  the  war  fighter  to  employ  proactive  measures.  This 
construct  will  improve  Operational  Availability  (Ao),  lower  TOC  and 
allow  Sailors  to  gain  more  technical  knowledge  and  skills. 

•  Optimized,  Reduced,  Minimal  and  Multi-Crew  Shipboard  Manning 
(Formerly  identified  as  ‘Minimal  Shipboard  Manning’)-New  ship 
programs,  such  as  LCS,  are  delivering  ships  based  on  the  assumption  that 
the  ships  can  be  staffed  minimally  and  leverage  off  of  improved  Distance 
Support.  Efficiency  of  technical  troubleshooting  is  the  key  to  allow  the 
ship’s  force  to  accomplish  their  diverse  tasking. 

The  results  from  both  the  SPY/Aegis  Task  Force  and  the  Distance  Support  CBA 
drove  the  team  towards  developing  a  solution  that  will  improve  Distance  Support 
effectively  and  increase  fleet  self-sufficiency.  From  the  initial  problem  statement,  project 
sponsors  believed  that  numerous  Distance  Support  tools  exist  but  need  to  be  consolidated 
and/or  integrated  more  effectively.  The  key  problem,  as  previously  stated,  is  that 
Distance  Support  activities  are  often  not  captured  for  knowledge  retention  and 
reutilization  and  the  knowledge  that  is  captured  is  difficult  to  access  and  utilize  in  a 
timely  manner.  It  is  this  particular  problem  that  this  capstone  research  seeks  to  address. 
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B.  RESEARCH  QUESTIONS 

The  following  research  questions  were  used  by  the  team  to  guide  their  research: 

•  Why  is  improving  the  Navy’s  Distance  Support  system  important  or 
necessary? 

•  How  do  others  conduct  Distance  Support  and  are  they  effective? 

•  How  do  the  stakeholders  define  an  effective  and  affordable  Distance 
Support  system? 

•  How  can  the  existing  Distance  Support  system  be  improved  or  modified  to 
increase  fleet  readiness  and  reduce  TOC? 

C.  PROJECT  ASSUMPTIONS  AND  CONSTRAINTS 

The  analyses  conducted  and  discussed  in  this  report  were  based  on  the  following 
assumptions: 

•  Demand  for  Distance  Support  will  increase  or  remain  constant 

•  Regional  Maintenance  Center  (RMCs),  who  are  on  the  waterfront  and  the 
ship’s  first  line  of  support  on  shore,  and/or  ISEA  technical  expertise,  will 
be  available  for  the  foreseeable  future 

•  RMCs/ISEAs  are  committed  to  Distance  Support  knowledge  capturing 
and  reutilization.  For  Distance  Support  to  be  a  helpful  and  useful  tool, 
buy-in  from  all  stakeholders  must  occur 

•  The  fleet  and  the  shore  support  activities  (to  include  the  RMCs  and 
ISEAs)  will  actively  participate  in  improving  Distance  Support 

•  Access  to  existing  Navy  data  capturing  and  knowledge  retention  databases 
will  be  permitted.  (Reusing  existing  data  is  critical  to  avoid  having  to 
create  duplicate  infrastructure  and  resources  for  capturing  Distance 
Support  experiences  and  knowledge) 

•  Information  contained  within  existing  knowledge  retention  databases  is 
sufficient  for  improving  fleet  self-help  and  performing  data  analysis. 
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Essentially,  the  assumptions  made  by  the  team  were  that  the  fleet  would  always  need 
remote  technical  help  and  the  USN  Activities  that  are  charged  with  technical  support  will 
continue  to  do  so.  Secure  connection  via  the  Web  to  the  technical  agents  is  also  required. 

D.  DESIGN  TEAM  STRUCTURE 

The  capstone  team  consisted  of  eight  distance-learning  students.  The  team  was 
co-located  at  Port  Hueneme,  California,  except  for  one  satellite  employee  located  in  San 
Diego,  California.  The  team  was  diverse  and  included  a  mix  of  senior  and  junior 
engineers  from  electrical,  electronics  and  computer  engineering  backgrounds.  Due  to 
travel  commitments  and  the  fact  that  one  employee  worked  at  a  different  location,  various 
tools  were  utilized  to  maintain  communication  including  web-based  meeting  platforms 
Defense  Connect  Online  (DCO)  and  Elluminate,  and  the  web-based  fde  sharing  service 
Dropbox.  In  addition,  weekly  team  meetings  and  class  sessions  were  utilized  for 
brainstorming  sessions,  discussing  the  status  of  projects  and  their  progress,  and  preparing 
class  materials  and  deliverables. 

To  execute  the  project,  the  team  utilized  a  matrix  organization  as  depicted  in 
Figure  3  that  applied  project  management  and  SE  disciplines  across  the  various  products 
required  for  a  solution.  The  chart  summarizes  the  team’s  roles  and  responsibilities. 
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Figure  3.  Design  Team 


13 


The  role  of  the  Project  Lead  was  to  ensure  the  project  was  on  schedule  and 
meeting  project  objectives  and  requirements.  Requirements  engineering  concerned  the 
development,  verification,  and  evaluation  of  all  capstone  project  requirements.  Cost 
Analysis  included  conducting  the  Business  Cost  Analysis  (BCA)  and  Return  on 
Investment  (ROI).  Architecture  design  included  the  development  and  design  of  the 
system  architecture.  This  task  translated  stakeholder  needs  into  system  functional 
requirements  and  decomposed  these  requirements  into  functional  architecture.  Risk 
management  covered  the  activities  of  conducting  risk  management,  performing  risk 
assessment,  and  providing  risk  mitigation.  Personnel  in  charge  of  the  AoA  were  tasked  to 
lead  the  evaluation  of  alternative  solutions.  All  team  members  were  involved  in  the 
writing  of  the  capstone  report.  The  administrative  members  were  responsible  for  taking 
notes  during  team  meetings,  keeping  track  of  action  items,  and  managing  all  other 
administrative  needs  that  may  develop  during  the  life  of  the  project. 

E.  STAKEHOLDERS  AND  PROJECT  SPONSORS 

A  list  of  stakeholders  and  their  primary  concerns  in  regard  to  this  project  is  given 
in  Table  1.  Based  upon  the  problem  definition  and  research  into  the  problem  domain,  the 
team  selected  seven  primary  stakeholders  to  focus  on  to  ensure  their  needs  were 
adequately  addressed.  The  project  was  principally  focused  on  improving  fleet  readiness; 
therefore  the  most  important  stakeholder  was  the  fleet  itself,  as  they  are  the  ultimate  users 
and  beneficiaries. 
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Stakeholder 

Primary  Concern 

Fleet 

Improve  fleet  readiness,  reduce  Total 

Ownership  Costs  (TOC) 

Waterfront  Activities 

Lack  of  adequate  Distance  Support  capabilities, 
capture  knowledge 

USN  Type  Commander  (TYCOM) 

Improve  fleet  readiness,  Distance  Support 
effectiveness,  system  performance  metrics 

Naval  Sea  Systems  Command 
(NAVSEA) 

Lack  of  adequate  Distance  Support  capabilities, 
reduce  Life  Cycle  Cost  (LCC) ,  system 
performance  metrics,  failure  trends 

Naval  Surface  Warfare  Center,  Port 
Hueneme  Division  (NSWC  PHD) 

Improve  fleet  readiness,  lack  of  adequate 

Distance  Support  capabilities,  capture 
knowledge,  and  reduce  LCC/TOC 

Program  Executive  Office  (PEO) 

Improve  Distance  Support  and  reduce  TOC, 
failure  trends,  acquisition  impacts 

Office  of  the  Chief  of  Naval 
Operations  (OPNAV) 

Improve  fleet  readiness  and  reduce  TOC 

Table  1.  Stakeholders 


While  effective  Distance  Support  can  improve  the  work  of  many  different 
stakeholders,  there  are  many  priorities  shared  by  all.  The  primary  concern  of  the  fleet  was 
to  minimize  equipment  down  time,  which  was  also  a  concern  shared  by  all  stakeholders. 
An  additional  concern  important  to  the  fleet  (and  all  stakeholders)  was  the  improvement 
of  equipment  reliability  and  the  reduction  of  TOC.  In  a  budget  constrained  environment, 
reducing  TOC  was  extremely  important  for  ensuring  an  affordable  Navy  for  the  future. 

All  of  the  project  sponsors  are  from  NSWC  PHD  and  are  listed  in  Table  2.  NSWC 
PHD,  as  the  ISEA  for  most  of  the  Navy’s  surface  weapon  systems,  has  the  unique  ability 
to  influence  and  address  stakeholder  concerns.  Knowledge  capturing  and  knowledge 
reutilization  are  key  components  to  enabling  NSWC  PHD  to  improve  component/system 
reliability  and  to  provide  faster,  more  thorough  Distance  Support  to  the  fleet,  all  of  which 
improves  fleet  readiness  and  while  reducing  TOC. 
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Sponsor 

Title 

Mr.  Timothy  Troske 

Technical  Director 

CAPT  Theodore  Olson,  USN 

Office  of  Logistics  (OOL),  Deputy  Commander 

Mr.  Fabio  Vitale 

OOL,  Director 

CAPT  Scott  Davis,  USN 

Chief  Engineer  (CHENG),  Office  of  Engineering 
Technology  (OET) 

Mr.  Dave  Scheid 

OET,  Chief  Innovations  Officer 

Mr.  David  Williams 

OET,  Distance  Support  Advocate 

Ms.  Coralyn  Akers 

Fleet  Liaison 

Mr.  John  Lester 

Systems  Engineering  (SE)-Air  Dominance  Department 
Lead 

Mr.  Noel  Camanag 

SE-Land  Attack  Department  Lead 

Mr.  James  Childs 

SE-Ship  Defense  and  Expeditionary  Warfare 
Department  Lead 

Table  2. 

NSWC  PHD  Project  Sponsors 

F.  SYSTEMS  ENGINEERING  PROCESS 

A  tailored  SE  process  was  used  to  reflect  the  uniqueness  of  the  project.  The  team 
adopted  the  new  2009  DoD  SE  Model  as  shown  in  Figure  4,  as  a  framework  for  the 
project  SE  process  due  to  its  standard  applicability  to  SE  projects  (Defense  Acquisition 
University  (DAU)  2011).  The  2009  DoD  SE  Model  consists  of  two  major  processes:  1) 
the  technical  management  process,  which  steers  system  development  to  meet  project  or 
phase  objectives,  and  2)  the  technical  processes,  which  are  depicted  in  a  V-shaped  pattern 
to  portray  the  “top-down”  design  that  occurs  as  requirements  are  allocated  from  the 
system  to  lower-level  elements.  The  V-shaped  model  also  shows  the  “bottom-up” 
realization,  from  the  lowest  level  components  to  higher  assemblies  to  achieve  the 
complete  system.  The  technical  processes  are  applied  across  the  life  cycle  of  a  system 
and  at  different  levels  in  the  system  hierarchy  to  develop  the  system  (DAU  2011). 
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TECHNICAL  MANAGEMENT  PROCESS 


Technical 

Risk 

Planning 
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Requirements 
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Configuration 

Management 

Technical  Data 
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Figure  4.  2009  DoD  System  Engineering  Model  (From  DAU  2011) 

The  team  used  the  tailored  SE  process  as  illustrated  in  Figure  5  for  activities 
in  the  development  of  the  capstone  project.  This  figure  reflects  the  project  activity 
hierarchy  that  was  pursued  as  the  team  progressed  through  the  SE  process.  The  first 
step  was  to  define  the  stakeholder  needs.  This  step  was  accomplished  by  reviewing 
past  studies  and  already  completed  surveys  provided  by  NSWC  PHD  project 
sponsors,  categorizing  the  results,  and  conducting  a  needs  analysis.  The  results  of  the 
needs  analysis  were  then  used  for  the  requirements  analysis.  After  completing  the 
requirements  analysis,  the  system  architecture  was  designed  and  modeled.  A 
preferred  solution  that  adequately  satisfies  stakeholder  requirements  was  then 
recommended  for  system  implementation. 
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Figure  5.  SE  Process  to  Project  Activities  (After  DAU  2011) 

Figure  6  shows  the  SE  process  used  for  mapping  stakeholder  needs  to  alternative 
solutions.  The  first  step  was  to  map  needs  to  requirements,  followed  secondly  by 
requirements  to  functions,  and  thirdly  functions  to  components.  The  mapping  process  not 
only  allowed  alternative  solutions  to  be  compared,  it  also  provided  traceability  back  to 
the  requirements.  The  Vitech  CORE®  modeling  tool  was  used  to  capture,  track,  and 
produce  the  SE  architecture  artifacts  which  will  be  discussed  in  more  detail  later  in  the 
report.  Through  CORE®,  the  requirements  were  mapped  into  a  hierarchy  and  then 
allocated  to  system  functions.  These  functions  were  then  tied  to  forms  or  components  for 
the  architecture. 
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Figure  6.  Requirements  to  Components  Mapping  Process 
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G.  SUMMARY 


The  project  development  methodology  was  to:  1)  apply  SE  techniques  to  clearly 
define  the  problem,  2)  prioritize  stakeholder  requirements,  3)  perform  a  functional 
analysis,  4)  research  and  compare  possible  solutions,  and  5)  develop  a  conclusion  and 
recommendation.  In  addition,  the  project  focused  on  finding  a  solution  to  determine  what 
methods  and  tools  were  needed  to  allow  Distance  Support  knowledge  and  experience  to 
be  captured  and  utilized  to  help  improve  Distance  Support  and  ultimately  fleet  readiness. 
The  stakeholder  needs  focused  on  developing  a  solution  that  would  aggregate  data  from 
numerous  existing  Distance  Support  sources,  export  data  to  the  fleet  to  promote  self-help, 
and  export  data  to  help  facilitate  trend  and  failure  analysis  opportunities.  Finally,  the 
project  scope  focused  on  improving  Distance  Support  knowledge  capturing  and 
reutilization  as  it  applies  to  NSWC  PHD.  Subsequent  chapters  of  this  report  will  discuss 
in  detail  these  SE  techniques  in  turn  and  outline  how  the  team  came  to  their  conclusion. 
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II.  DEFINING  STAKEHOLDER  NEEDS 


The  first  step  of  the  SE  process  was  to  define  stakeholder  needs.  This  was  an 
important  first  step  to  developing  a  conceptual  design  of  the  system  that  would  provide 
the  stakeholders  with  a  preferred  solution.  “Having  defined  the  problem  completely  and 
thoroughly,  a  needs  analysis  should  be  performed  with  the  objective  of  translating  a 
broadly  defined  ‘want’  into  a  more  specific  system-level  requirement”  (Blanchard  and 
Fabrycky  201 1,  58). 

A.  DERIVING  STAKEHOLDER  NEEDS 

The  first  step  taken  after  developing  the  initial  problem  statement  was  to 
determine  the  stakeholder  needs.  To  help  with  this,  the  team  met  with  key  NSWC  PHD 
sponsors,  Dave  Scheid  and  David  Williams,  and  solicited  their  guidance  on  how  best  to 
approach  this  task.  In  addition  to  providing  guidance,  the  sponsors  also  provided  past 
Distance  Support  studies  that  were  previously  conducted. 

Two  of  the  studies  utilized  by  the  team  were  summarized  in  Chapter  I.  In 
addition,  the  team  was  also  provided  survey  results  that  were  originally  used  to  develop 
the  LCS  Distance  Support  philosophy.  The  survey  results  are  not  releasable  to  the  general 
public.  In  summary,  this  report  details  the  methodology,  findings,  and  recommendations 
following  three  days  of  Culture  Mapping  Sessions  held  in  Naval  Base  San  Diego  and  at 
NSWC  PHD  in  January  of  2012.  Culture  mapping  methodology  included  several  small 
group  sessions  which  encouraged  anecdotes  on  the  current  state  of  Distance  Support  and 
then  were  “mapped”  to  determine  a  more  complete  understanding  of  its  nature.  These 
sessions  were  also  conducted  to  understand  the  Distance  Support  processes  and  functions 
across  the  fleet  and  discern  the  challenges  to  Distance  Support  that  LCS  may  present  as  a 
unique  mission  platform.  To  NSWC  PHD  sponsors,  these  results  were  very  important 
because  the  LCS  shipboard  manning  is  expected  to  be  significantly  lower  than  traditional 
war  ships,  which  means  that  LCS  ships  will  be  more  dependent  on  Distance  Support  than 
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ever  before.  One  of  the  most  important  findings  from  the  culture  mapping  reports  was 
learning  that  to  be  useful,  a  tool  must  be  simple  to  operate  and  be  quick  to  provide  help. 

The  stakeholder  needs  were  derived  from  the  LCS  Culture  Mapping  Sessions  and 
the  past  Distance  Support  studies.  The  stakeholder  needs  were  then  organized  and  re¬ 
written  in  terms  of  requirements.  Requirements  are  discussed  in  more  detail  later  in  the 
report. 

B.  NEEDS  ANALYSIS 

By  performing  a  thorough  stakeholder  needs  analysis,  the  team  determined  that 
NSWC  PHD  needed  to  improve  Distance  Support  data  aggregation  and  knowledge 
reutilization  in  order  to  provide  more  effective  Distance  Support  capability  to  the  fleet.  In 
addition,  improved  data  aggregation  enables  NSWC  PHD  to  perform  more  effective  trend 
analysis  to  improve  equipment  reliability,  utilizing  existing  shore  support  resources  and 
processes. 

When  a  failure  occurs  with  a  shipboard  system,  Sailors  normally  engage  in 
troubleshooting  efforts  to  isolate  the  failed  component  based  on  their  own  experience. 
Sailors  are  usually  motivated  to  correct  the  failure  as  quickly  as  possible  and  if  this  effort 
is  prolonged,  the  Sailor  will  look  for  assistance  from  others.  The  first  priority  is  to 
exhaust  the  resources  available  on  the  ship  and  once  that  occurs,  the  Sailor  will  pursue 
assistance  from  ashore.  The  typical  process  is  to  contact  the  local  RMC  and  if  those 
resources  are  not  readily  available  then  they  often  contact  the  ISEA.  The  last  resort  is 
usually  to  contact  the  Original  Equipment  Manufacturer  (OEM).  To  summarize,  the 
current  process  is  usually  time  consuming  and  significantly  prolongs  system  down  time. 

In  today’s  environment  where  ships  are  a  limited  resource,  Sailors  have  more 
collateral  duties  and  have  very  little  time  for  combat  system  maintenance.  To  avoid 
lengthy  troubleshooting  sessions,  Sailors  often  prefer  someone  telling  them  what 
component  to  replace  and  how  to  replace  it.  An  analogy  would  be  that  the  “check  engine” 
light  in  a  car  goes  on  so  the  owner  takes  the  car  to  the  dealer  for  a  diagnosis.  The  dealer 
quickly  determines  which  parts  have  failed.  The  owner  can  then  buy  the  parts  and  install 
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them  or  have  the  dealer  install  them.  In  that  scenario,  the  problem  gets  fixed  with  the 
least  amount  of  the  car  owner’s  time  consumed.  Thus,  the  requirements  for  help  can  be 
colloquially  summarized  as  follows: 

•  Determine  what’s  broken  with  the  system  (i.e.,  what  failed  or  what’s  not 
working  right) 

•  Determine  what  parts  need  to  be  ordered  and  from  where  (in  the  most 
expeditious  way) 

•  Determine  how  to  replace  the  parts 

•  Determine  what  to  do  with  the  old  parts. 

Using  the  analogy  above  and  feedback  from  stakeholders,  the  following  general 
statements  seem  to  capture  some  of  the  most  important  self-help  requirements  for  the 
Navy.  Operators  need: 

•  Help  with  operation  and  maintenance 

•  Quick  access  to  the  right  information  or  resources  (including  people) 

•  Useful  and  effective  information  or  assistance 

•  Information  that  is  easy  to  understand  and  follow  information 

•  Help  that  is  immediate  or  information  regarding  who  to  contact  for  more 
help. 

According  to  the  stakeholders,  the  most  effective  Distance  Support  system  would 
include  the  ability  to  conduct  prognostics  to  predict  failures  in  advance  and  replace 
defective  components  before  they  fail;  this  would  mean  that  equipment  would  be 
replaced  at  a  more  convenient  time  than  would  be  the  case  if  equipment  was  replaced 
because  of  failure  or  at  an  unanticipated  time.  In  the  absence  of  prognostic  capability, 
which  has  not  yet  fully  matured,  the  most  effective  Distance  Support  system  would 
emulate  having  fully  knowledgeable  technical  experts  and  complete  parts  support  on 
board  a  ship  so  that  when  a  combat  system  experiences  a  failure,  the  root  cause  can  be 
determined  without  delay  and  the  failure  corrected  immediately.  In  regards  to 
maintenance,  minimizing  down  time  is  the  key  element  of  achieving  high  Ao  and  the 
highest  state  of  fleet  readiness.  Any  delays  in  replacing  failed  components  results  in 
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longer  down  times.  As  discussed  previously,  in  today’s  Navy  not  all  parts  are  available 
on  board  and  the  availability  of  technical  experts  is  limited.  The  most  knowledgeable 
technical  experts  are  not  shipboard  and  reside  on  shore  at  various  organizations.  These 
organizations  include  the  RMCs,  the  ISEAs,  and  the  OEMs.  If  it  were  possible  to  place  a 
SME  on  every  ship,  the  need  for  Distance  Support  would  be  eliminated.  Since  these 
resources  are  mostly  civil  servants  and  private  parties,  it  is  not  possible  to  position  these 
resources  on  a  Navy  war  ship,  especially  in  combat.  Technical  experts  consist  of  trained 
professionals  with  the  most  knowledge,  skills,  and  abilities;  the  expertise  of  such  a 
technical  expert  is  difficult  to  have  shipboard.  The  turnover  frequency  of  active  duty 
military  personnel  alone  prevents  sufficient  retention  of  fully  trained  individuals. 
Therefore,  the  goal  of  an  effective  Distance  Support  system  are  to  provide  immediate 
access  to  the  SMEs,  share  as  much  system  fault  information  with  that  SME,  and  provide 
the  ship  with  immediate  access  to  the  knowledge  that  the  technical  experts  possess 
without  having  to  contact  or  position  the  technical  expert  on  site. 

From  the  stakeholder  needs  analysis,  the  ideal  solution  would  meet  the  following 
criteria  for  knowledge  and  technical  information: 

•  Easily  accessible 

•  High  Quality  information  (accurate,  useful,  reliable,  and  complete) 

•  Data  sorted  by  its  age  (i.e.,  providing  most  recent  information) 

•  Well  organized  data 

•  Information  displayed  and/or  reported  when  needed. 

Past  Distance  Support  surveys  and  studies  showed  that  Sailors  usually  avoid  using 
any  process  or  tool  that  does  not  meet  the  above  criteria.  Thus,  providing  Sailors 
immediate  access  to  technical  information  that  meets  the  above  criteria  should  improve 
self-help.  This  change  would  reduce  the  need  to  contact  SMEs  ashore. 

Ship-to-shore  access  to  technical  information  currently  exists  but  is  often  slow  or 
difficult  to  access  and  utilize.  The  primary  vehicles  for  accessing  technical  information 
include  websites,  electronic  media  like  Compact  Disks  (CD),  and  e-mail.  E-mail  is 
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currently  the  most  convenient  method,  but  Sailors  often  experience  delays  because  of  not 
knowing  who  to  contact,  different  time  zones,  and  SME  availability.  Although  e-mail  is 
often  slow,  it  is  usually  effective  at  getting  help  to  the  ships,  eventually.  Ships  have 
bandwidth  limitations  that  often  prevent  Sailors  from  accessing  and  searching  the 
numerous  websites  that  are  available,  especially  while  deployed.  In  addition,  many 
Sailors  are  often  not  aware  of  the  websites  that  are  available,  including  the  NSWC  PHD 
Sailor  to  Engineer  (S2E)  website.  Numerous  websites  exist,  but  contain  limited 
information  and  are  usually  only  updated  as  a  need  arises,  websites  are  convenient  but 
rarely  meet  the  required  attributes  for  Distance  Support,  which  are  easily  accessible,  high 
quality  information,  most  recent  data,  and  well  organized.  Thus,  Sailors  rarely  prefer  to 
utilize  websites  because  they  fail  to  meet  the  minimum  Distance  Support  criteria 
provided  above. 

Technical  and  recorded  information  that  resides  on  unique  databases  and  servers 
is  also  difficult  for  Sailors  to  access.  Typically,  to  have  access,  a  user  is  required  to  obtain 
permission  to  use  the  information  contained  in  the  database.  Once  permission  is  provided, 
finding  useful  information  can  be  extremely  difficult  and  time  consuming.  On  the  other 
hand,  many  databases  are  routinely  updated  by  the  host  organization  and  usually  contain 
the  most  recent  historical  information.  In  addition  to  technical  information,  information 
related  to  maintenance  performed  by  others  and  past  Distance  Support  experiences  is 
often  captured  in  these  databases.  SMEs  also  rely  on  this  technical  and  historical 
information  for  conducting  technical  assistance.  The  ability  to  extract  and  display 
information,  automatically  when  needed,  could  significantly  increase  self-help 
capabilities. 

C.  OPERATIONAL  CONCEPT  DEFINITION 

The  team  defined  a  system  that  would  answer  all  the  needs  described  by  the 
stakeholders  and  referred  to  it  as  the  Data  Aggregation  System  (DAS).  The  operational 
concept  of  the  DAS  was  to  aggregate,  and  integrate  engineering  and  supportability 
information  from  internal  and  external  sources  and  to  capture  SMEs  knowledge  to 
improve  today’s  and  tomorrow’s  fleet  readiness  through  Distance  Support  capabilities. 
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The  system  will  enhance  the  effectiveness  and  efficiency  of  near  real-time  data 
management  and  utilization  by  providing  benefits  in  the  following  ways: 

•  Providing  maintenance  information  to  enable  fleet  self  help 

•  Providing  insight  to  help  predict  potential  problems  before  they  occur  by 
utilizing  Key  Performance  Indicator  (KPI)  “triggers”  to  help  focus  SMEs 
on  the  pertinent  issues  for  their  systems 

•  Addressing  engineering  and  supportability  issues  quickly  by  automating 
data  collection/aggregation  from  a  variety  of  available  sources 

•  Assisting  sponsors  and/or  customers  in  prioritizing  requirements  within 
the  budget  cycle 

•  Managing  engineering  expertise  and  knowledge  effectively 

•  Providing  accurate  and  repeatable  results  through  standardization  of  fault 
diagnostics  and  repair 

•  Providing  the  ability  to  efficiently  display  baseline  or  combat  system 
cumulative  reporting  across  the  enterprise  in  support  of  organizational, 
programmatic,  or  individual  needs 

•  Providing  timely  and  accurate  information  to  the  SME  for  fleet  technical 
assistance  via  Distance  Support 

•  Providing  the  ability  to  produce  special  reports  quickly  and  more  cost 
effectively 

•  Capturing  corporate  knowledge  from  the  SMEs,  situations,  and  processes 
continuously  and  make  available  for  training  and  future  reference/analysis 

•  Maintaining  historical  records  and  related  corporate  knowledge  that  is 
easily  retrieved  by  any  user. 

The  diagram  shown  in  Figure  7  describes  the  concept  operation  of  the  DAS  where 
multiple  data  sources  are  collected  either  from  the  ships  or  from  various  fleet  support 
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agencies.  After  the  data  is  collected  through  a  network  interface,  the  system  will  then 
process  and  analyze  the  data  to  generate  multiple  products  that  are  categorized  as 
follows: 

•  Performance  Health  Trigger,  which  is  a  key  parameter  with  a  threshold 
associated  to  it  directly  related  to  the  performance  of  a  system 

•  Corrective  Maintenance  Solutions  are  considered  as  equipment 
troubleshooting  tips  provided  by  the  SMEs,  list  of  common  equipment 
failure  items  and  common  corrective  actions,  updated  troubleshooting 
procedures  and  maintenance  work  packages,  part  list,  and  many  more 
products  that  can  be  used  for  self-help  corrective  maintenance 

•  Predictive  Analysis  and  Modeling,  or  forecasting  future  states  and  issues 
of  the  system  based  on  historical  data 

•  Operational  Data  Analysis;  analysis  of  ship’s  system  performance  based 
on  different  mission  area 

•  Statistic  Modeling,  results  from  system  testing  and  Reliability, 
Maintainability,  and  Availability  (RMA)  data  collected  over  time  can  be 
used  to  create  statistic  model  for  future  trending  and  predictive  analysis 

•  Data  Validation;  ship’s  system  performance  and  system  configuration  data 
will  be  collected,  measured  and  validated  with  specification  requirements 
for  accuracy  and  effectiveness. 

The  arrows  in  the  center  of  Figure  7  that  are  pointing  to  the  top  of  the  diagram 
reflect  information  and  knowledge  being  reused  and  shared  with  both  the  fleet  and  shore 
support  organizations.  The  data  aggregation  occurring  in  the  middle  is  the  primary  focus 
of  this  capstone  project. 
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Figure  7.  Data  Aggregation  System  Operational  Concept 


1.  DAS  Users 


In  the  context  of  operation,  the  “user”  is  defined  as  anyone  who  utilizes  the  DAS 
to  analyze  data  or  obtain  information.  A  user  can  be  a  SME  of  a  particular  system,  fleet 
customer,  or  sponsor  who  has  the  need  to  see  the  system  life  cycle  data.  Additional 
details  on  how  each  of  these  users  will  utilize  the  Data  Aggregation  are  described  in  the 
following  paragraphs. 


a.  SME 

Equipment,  software,  and  systems  engineers,  as  well  as  supportability  and 
financial  personnel  will  use  the  DAS  as  a  resource  to  conduct  engineering  and 
supportability  investigations.  The  DAS  will  allow  the  SME  to  review  multiple  data 
sources,  such  as  technical  assistance  data  generated  by  the  Command  Issues  Management 
(CIM),  remote  system  diagnostic  and  assessment  reports  resulted  from  Operational 
Readiness  Test  System  Tech  Assist  Remote  Support  (ORTSTARS),  testing  Maintenance 
and  Material  Management  (3M)  data  which  contains  RMA  data  imported  from  the 
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Material  Readiness  Database  (MRDB),  supply  data  collected  from  the  Naval  Supply 
Systems  Command  (NAVSUP)  database,  and  so  forth.  These  users  would  utilize  the  data 
to  conduct  root  cause  analysis  and  develop  a  possible  solution  to  issues. 

b.  Fleet  Customer 

The  USN  fleet,  RMC  personnel,  USFFC,  Type  Commanders  (TYCOMs), 
and  Class  Squadrons  (CLASSRON)  will  use  the  DAS  as  a  data  source  which  will  provide 
pertinent  data  needed  to  assist  with  fleet  responses  to  system  and  equipment  maintenance 
and  performance  issues.  These  issues  may  include  common  questions  and  answers 
pertaining  to  equipment  corrective  maintenance,  troubleshooting  procedures,  metrics, 
information  on  issues  that  the  SME  has  analyzed,  fleet  issues  addressed  previously,  or 
other  concerns  investigated  by  the  ISEA. 

c.  Program  Sponsors 

Sponsors  such  as  NAVSEA,  Program  Executive  Office,  Integrated 
Warfare  Systems  (PEO  IWS),  Program  Executive  Office,  Ships  (PEO  SHIPS),  Program 
Manager,  Sea  Navy  Theater  Wide  Program  Office  (PMS  452),  USN  Missile  Defense 
Agency  (MDA)  and  NSWC  PHD  will  use  the  DAS  information  and  results  of 
engineering  and  supportability  investigations  to  assist  them  in  making  high-level 
decisions  based  on  historical  data,  trends,  fleet  usage,  and  emergent  issues. 

2.  DAS  Data 

The  DAS  will  access  the  data  from  multiple  sources  through  a  network  interface 
connected  through  the  Navy’s  existing  network  infrastructure.  Based  on  the  team’s 
research,  the  databases  discussed  in  the  following  subsections  were  identified  as 
prominent  data  sources  that  will  be  accessed  and  processed  by  the  DAS.  These  databases 
contain  a  significant  amount  of  information  and  most  are  routinely  updated  with  new 
information  as  it  becomes  available.  Most  of  this  information  is  currently  used  by  ISEAs, 
shore  support  maintenance  personnel  and  the  supply  system  to  track  system 
configurations,  system  performance,  maintenance  actions,  and  to  improve  system 
reliability.  Shipboard  Sailors  rarely  possess  or  attempt  to  access  the  information 
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contained  within  these  databases,  primarily  due  to  a  lack  of  awareness  of  the  databases’ 
existence  or  utility,  difficultly  accessing  information,  or  the  need  to  obtain  permission. 
The  information  contained  within  these  databases  is  extremely  useful  for  sharing  past 
Distance  Support  experiences  and  for  identifying  reliability  improvement  opportunities. 
In  addition,  much  of  the  knowledge  that  SMEs  possess  is  captured  within  these 
databases.  The  DAS  will  be  a  tool  that  will  process  this  information  in  a  way  that  satisfies 
the  Distance  Support  criteria,  improving  the  self-help  capability.  To  satisfy  the  Distance 
Support  criteria  developed  in  this  report,  the  data  will  have  to  be  aggregated  such  that  the 
information  is  readily  accessible,  high  quality,  and  well  organized. 

a.  NA  VSEA  Logistics  Center  (NSLC)  Maintenance  and  Material 
Management  (3M) 

The  3M  repository  contains  shipboard  created  deferred  and  non-deferred 
jobs,  shore  facility  jobs  created  in  support  of  ships,  and  information  related  to  the 
planning  of  deferred  maintenance.  The  repository  also  contains  Intermediate  Maintenance 
Activity  job  completion  information  and  some  public/private  depot  level  completion  data 
for  off-ship  maintenance.  Supply  transactions  that  associate  supply  demands  to  shipboard 
and  non-shipboard  issues  are  available  within  the  new  repository.  Preventive 
Maintenance  (PMS)  completion  information  is  also  available.  The  database  has  been 
enhanced  to  include,  metrics  at  the  job  level  and  a  breakout  of  Selective  Level  Reporting 
information  from  in-stream  narrative  to  fielded  table  information. 

DAS  will  obtain  3M  data  for  two  main  reasons,  which  are  to  obtain  ship 
and  equipment  configuration  information  and  ship  and  equipment  field  maintenance 
information.  This  information  is  used  to  provide  System  Operational  Effectiveness  (SOE) 
metrics,  which  are  Mean  Time  Between  Failures  (MTBF),  cost,  number  of  failures  due  to 
human  factors,  and  so  forth. 

b.  Command  Issues  Management  (CIM) 

CIM  is  an  application  which  is  being  used  to  track  all  NSWC  PHD  fleet 
technical  assistances,  and  other  types  of  work,  for  instance  program  action  items,  trend 
analysis,  system  anomalies,  engineering  investigations,  and  so  forth.  DAS  will  obtain 
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CIM  data  to  report  the  effectiveness  of  NSWC  PHD’s  support  to  the  Fleet.  Some 
examples  of  CIM  metrics  are:  1)  Technical  Assistances  (TA)  open  greater  than  or  equal 
to  90  days  at  the  end  of  the  month,  2)  TA  costs  due  to  closed  TAs  open  less  than  90  days, 
and  3)  TA  productivity  metrics  for  TAs  closed  less  than  90  days. 

c.  Test  Observation  Reports  (TORs) 

The  TORs  database  contains  Test  Observation  Reports  from  Combat 
System  Ship  Qualification  Trial  (CSSQT)  and  other  test  events  in  which  NSWC-PHD 
participates.  DAS  will  obtain  TOR  data  to  report  system  Probability  of  No  Human  Error 
(Pp)  metrics  and  Human  System  Integration  (HSI)  information  as  part  of  NSWC  PHD’s 
Safety  Effective  and  Affordable  Review  (SEAR)  process.  TOR  HSI  elements  are  as 
follows:  1)  human  factors,  2)  personnel,  3)  habitability,  4)  manpower,  5)  training,  6) 
survivability,  and  7)  environment,  safety  and  occupational  health. 

d.  Engineering  Information  System  (EIS)  Problem  Description 
Database  (PDDB) 

The  EIS  PDDB  contains  engineering  problem  description  reports  for 
investigations  in  which  NSWC-PHD  participates.  DAS  will  obtain  EIS  PDDB  data  to 
report  open  and  closed  engineering  investigations  on  equipment. 

e.  General  Distribution  Allowance  Parts  List  (GDAPL) 

The  Navy’s  General  Distribution  Allowance  Parts  List  (GDAPL)  cross- 
references  part  numbers,  National  Stock  Numbers  (NSNs)  and  Commercial  and 
Government  Entity  (CAGE)  Codes  to  Allowance  Part  Lists  (APLs).  Obtained  from  the 
Navy  Ships  Parts  Control  Center  (SPCC),  this  database  shows  top-down,  bottom-up 
relationships  between  all  parts  in  the  system.  GDAPL  is  a  Microsoft®  Windows  based 
application;  it  contains  a  current  drawdown  of  the  Weapon  Systems  File  for  APLs  and 
Allowance  Equipment  Lists  (AELs)  as  of  the  date  of  extraction.  The  GDAPL  is  a 
quarterly  issued  item,  and  is  distributed  in  October,  January,  April,  and  July.  DAS  will 
obtain  GDAPL  information  to  develop  equipment  configuration  management  tables  that, 
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in  turn,  support  SOE  metrics.  For  more  information  on  GDAPL,  visit  the  website: 
http://www.navicp.navy.mil/05/caprod.htm. 


f.  Material  Readiness  Database-Next  Generation  (MRDB-NG) 

MRDB-NG  data  is  a  consolidation  of  validated  3M,  Casualty  Report 
(CASREP),  employment,  cost,  equipment  identification  code,  and  other  information 
which  is  then  used  to  generate  overall  equipment  Ao,  MTBF,  Mean  Time  To  Repair 
(MTTR),  support  indices,  and  other  logistics  and  sparing  indices  at  the  system  level. 
Equivalent  indices  and  cost  of  replacement  parts  are  also  generated  at  the  block  and  part 
level.  DAS  will  obtain  MRDB-NG  information  for  equipment  Ao  metrics  that,  in  turn, 
supports  SOE  metrics. 


g.  Navy  Data  Environment  -Afloat  Master  Planning  System  ( NDE - 
AMPS) 

The  Afloat  Master  Planning  System  (AMPS)  provides  data  on  major 
shipboard  systems  (Configurations)  with  a  focus  toward  Battle  Force  interoperability.  It 
also  carries  planning  information  about  scheduled  Installations,  Alterations  and 
Configuration  Changes.  DAS  will  obtain  AMPS  data  for  Strike  Group  configuration 
information  that,  in  turn,  supports  SOE  metrics  grouping  at  the  strike  group  level.  For 
more  information  on  NDE-AMPS,  visit  the  website:  https://www.nde.navy.mil/. 

h.  Global  Distance  Support  Center  (GDSC)  Remedy 

The  GDSC  Remedy  is  a  virtual  call  center  connecting  Fleet  and  Industrial 
Supply  Center  (FISC)  Norfolk  and  San  Diego  to  process  customer  requests  for 
information,  products  and  services  from  the  logistics  system.  DAS  will  obtain  GDSC 
Remedy  data  to  report  to  NSWC  PHD  the  effectiveness  of  NSWC  PHD’s  support  to  the 
Fleet.  Some  examples  of  GDSC  Remedy  metrics  are:  1)  TAs  open  greater  than  or  equal 
to  90  days  at  the  end  of  the  month,  2)  TA  costs  due  to  TAs  closed  in  less  than  90  days, 
and  3)  TA  productivity  metrics  for  TAs  closed  in  less  than  90  days.  For  more  information 
on  GDSC  Remedy,  visit  the  website:  http://www.anchordesk.navy.mil/. 
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1. 


Diminishing  Manufacturing  Sources  and  Material  Shortages 
(DMSMS) 


The  Government-Industry  Data  Exchange  Program  (GIDEP)  is  a 
cooperative  effort  to  exchange  research,  development,  design,  testing,  acquisition,  and 
logistics  information  among  government  and  industry  participants.  DMSMS  notices 
originate  when  a  part  manufacturer  announces  that  a  part  or  a  production  line  will  be 
discontinued.  The  majority  of  GIDEP  DMSMS  notices  have  been  issued  on  piece  parts, 
especially  in  the  electronics  area  (primary  microcircuits);  however,  DMSMS  also  occurs 
at  the  module,  component,  equipment,  or  other  system  indenture  level.  GIDEP  is 
designated  as  the  Department  of  Defense  centralized  database  for  managing  and 
disseminating  DMSMS  information.  The  database  contains  data  for  not  only  parts 
manufactured  in  accordance  with  military  or  government  specification  but  also 
commercial  parts.  DAS  will  obtain  DMSMS  data  to  identify  Lowest  Replaceable  Units 
(LRUs)  that  are  of  concern  to  the  ISEA  because  they  are  or  will  be  obsolete.  For  more 
information  on  DMSMS,  visit  the  website:  http://www.gidep.org/. 

j.  Federal  Logistics  Data  (FEDLOG)  Information  Center 

FEDLOG  can  be  used  by  engineering,  technical  research,  provisioning, 
procurement/contracting,  supply,  cataloging,  maintenance,  distribution,  storage, 
transportation,  quality  assurance  and  disposal  personnel  to  retrieve  management, 
part/reference  number,  supplier,  commercial  and  government  entity,  freight, 
Interchangeability  and  Substitutability  (I&S)  and  characteristics  information  recorded 
against  NSNs.  FEDLOG  also  provides  service  unique  data  for  additional  search 
capabilities.  FEDLOG  is  published  monthly  on  Compact  Disk-Read  Only  Memory  (CD- 
ROM)  and  Digital  Video  Disc  (DVD)  by  the  Defense  Logistics  Information  Service 
(DLIS).  DAS  will  obtain  FEDLOG  information  to  develop  a  National  Item  Identification 
Number  (NUN)  to  CAGE  and  part  number  cross-reference  table  because  LRUs  may  be 
referred  to  by  part  number  by  engineers  and  by  NUN  by  logisticians.  For  more 
information  on  FEDLOG,  visit  the  website:  http://www.nslc.navsea.navy.miE. 
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k.  Program  Information  System  Mission  Services  (PRISMS) 

The  PRISMS  database  contains  the  configuration  data  used  by  the  Board 
of  Inspection  and  Survey  (INSURV)  to  conduct  their  inspections.  DAS  will  use  PRISMS 
information  to  support  INSURV  information-based  products. 

/.  Navy  Data  Environment  (NDE)  -  Configuration  Data  Managers 
Database  Open  Architecture  (CDMD-OA) 

The  CDMD-OA  tracks  the  status  and  maintenance  of  naval  equipment  and 
their  related  logistics  items,  such  as  drawings  and  manuals,  on  ships  and  naval  activities 
around  the  world.  The  term  “open  architecture”  is  used  to  denote  the  fact  that  CDMD-OA 
is  a  client/server-based  system,  not  dependent  upon  any  vendor’s  proprietary  hardware  or 
software;  data  may  flow  to  and  from  CDMD-OA  provided  that  open  protocols  are  used. 
The  status  of  a  given  piece  of  equipment  on  a  ship  determines  what  and  how  many  spare 
parts  will  be  stored  on  that  ship  for  it,  making  this  tracking  extremely  important  in  terms 
of  cost,  shipboard  space  and  weight,  and  the  operational  availability  of  the  ship.  DAS  will 
obtain  CDMD-OA  information  for  ship  /  equipment  configuration  information.  For  more 
information  on  NDE  CDMD-OA,  visit  the  website:  https://www.nde.navy.mil/. 

m.  Trouble  Feedback  Reports  (TFBRs) 

The  TFBRs  database  contains  records  of  equipment  malfunction  events 
that  occurred  at  the  Aegis  production  test  center  and  shipyard.  TFBR  information  will  be 
used  for  production  and/or  integration  performance  metrics  that,  in  turn,  support  SOE 
metrics. 


n.  Safety  Hazard  Alert  Reports  (SHARs) 

The  SHARs  database  contains  Safety  Working  Group  investigation 
summaries  for  Aegis  ships.  SHAR  data  will  be  used  to  support  safety  metrics  that,  in 
turn,  supports  NSWC  PHD’s  SEAR  process. 
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o.  NDE-Navy  Modernization  (NDE-NM) 

NDE-NM  is  a  database  that  tracks  and  maintains  logistical  data  for 
modernizing  ships  in  the  Navy.  NDE-NM  stores  engineering  information,  alteration 
information,  automated  tracking  of  materials  usage  and  requirements,  alteration 
scheduling  and  completion  status  and  detailed  shipyard  scheduling.  DAS  will  obtain 
NDE-NM  information  to  identify  ship  availabilities,  their  duration,  and  when  they 
occurred.  This  information  is  used  to  derive  operating  times  that,  in  turn,  supports  SOE 
metrics.  For  more  information  on  NDE-NM,  visit  the  website: 
https://www.nde.navy.mil/. 

p.  Visibility  and  Management  of  Operating  and  Support  Costs 
(VAMOSC) 

The  Navy  VAMOSC  management  information  system  collects  and  reports 
USN  and  U.S.  Marine  Corps  (USMC)  historical  weapon  system  Operating  and  Support 
(O&S)  costs.  VAMOSC  provides  the  direct  O&S  costs  of  weapon  systems,  some  linked 
indirect  costs  (e.g.,  ship  depot  overhead),  and  related  non-cost  information  such  as  flying 
hour  metrics,  steaming  hours,  age  of  aircraft,  and  so  forth.  VAMOSC  has  recently  added 
the  military  personnel  database,  which  contains  all  active  duty  USN  and  USMC 
personnel  costs  and  attributes  data.  DAS  will  obtain  VAMOSC  data  to  support 
affordability  metrics  that,  in  turn,  supports  NSWC  PHD’s  SEAR  process.  For  more 
information  on  VAMOSC,  visit  the  website:  http://www.oscamtools.com/Vamosc.htm. 

q.  Aegis  Configuration  Control  and  Engineering  Status  System 
(ACCESS) 

The  ACCESS  database  contains  data  for  ship  /  baseline  configuration 
information  and  for  alteration  information.  DAS  will  use  ACCESS  data  to  group  ships  by 
baseline  and  to  determine  if  and  when  an  alteration  has  been  installed  on  a  particular  ship. 

r.  Board  of  Inspection  and  Survey  (INS  UR  V) 

The  INSURV  is  tasked  with  conducting  material  inspections  and  surveys 
of  ships  and  service  craft  and  providing  an  assessment  of  the  material  readiness  of  these 
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vessels  to  Congress  and  Navy  leadership.  DAS  will  use  INSURV  material  readiness 
information  to  support  NSWC  PHD’s  SEAR  process  and  INSURV  results  data  analysis. 

s.  Aegis  Weapon  System  (A  WSJ  Part-to-Block 

AWS  Part-to-Block  is  data  from  the  OEM  that  lists  AWS  LRUs,  the  block 
in  the  reliability  block  diagram  they  belong  to,  the  quantity  of  each  in  each  block,  the 
criticality  of  the  part  to  the  block  and  to  AWS,  and  the  minimum  quantity  of  parts 
required  to  be  operational  within  the  block. 

t.  Sailor  To  Engineer  (S2E) 

S2E  is  a  web-based  portal  hosted  by  NSWC  PHD  that  provides  Sailors  the 
instant  access  to  engineering  and  logistics  experts  at  NSWC  PHD  and  other  NSWC 
commands.  The  S2E  page  is  a  source  of  information  for  solving  problems  and  answering 
questions  regarding  combat/weapon  systems,  hull,  mechanical,  and  electrical  systems,  or 
underway  replenishment  performance  and  maintenance. 

u.  Aegis  Combat  System  Reliability  Maintainability  Supportability 
(ACSRMS) 

The  ACSRMS  database  is  comprised  mostly  of  database  objects  germane 
to  the  Aegis  Combat  System  (ACS).  ACSRMA  includes  data  from  the  following 
databases:  ACCESS,  GDAPL,  PDDB,  SHARs,  and  TFBRs.  Depending  on  the 
completeness  of  the  data  contained  in  ACSRMS,  DAS  may  just  obtain  the  data  directly 
from  ACSRMS  instead  of  query  the  data  from  original  sources. 

D.  SUMMARY 

From  the  needs  analysis,  it  was  determined  that  the  stakeholders  needed  a  system 
that  provides  easily  accessible  data,  high  quality  information,  current  data,  well  organized 
information,  and  information  displayed  and  reported  when  needed.  An  operational 
concept  diagram  was  developed  to  show,  at  a  very  high  level,  the  operational 
relationships  amongst  users  and  the  new  proposed  DAS.  Chapter  III  discusses  how  these 
needs  were  mapped  to  system  requirements,  then  to  functions,  as  well  as  the  AoA  that 

was  conducted  to  determine  the  best  alternative  that  answers  the  stakeholder’s  needs. 
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III.  REQUIREMENTS  ANALYSIS 


The  second  step  in  the  SE  process,  after  defining  stakeholders’  needs,  was  to 
conduct  the  requirements  analysis  that  identified  the  operational,  functional,  physical,  and 
performance  requirements  (Blanchard  and  Fabrycky  2011).  The  requirements  analysis 
process  was  necessary  to  translate  the  needs  of  the  stakeholders  into  an  operational 
scenario.  This  assisted  with  the  development  of  the  set  of  system  operational 
requirements,  the  maintenance  and  support  concepts,  and  the  identification  of  Measures 
of  Effectiveness  (MOE)  and  Measures  of  Performance  (MOP).  These  requirements  and 
measures  were  then  used  to  compare  the  operational  suitability  of  alternatives  so  that  the 
most  effective  solution  was  chosen  based  on  a  sound  scientific  process. 

A.  DEFINING  STAKEHOLDER  REQUIREMENTS 

Requirements  were  used  to  determine  the  functional  and  physical  characteristics 
for  the  integration  and  design  considerations  of  the  DAS.  Figure  8  shows  a  simplified 
view  of  the  requirements  generation  process  as  it  relates  to  the  other  major  SE  tasks 
within  this  project.  As  the  figure  depicts,  requirements  drive  system  functions  that  in  turn 
drive  physical  components  considerations.  An  architecture  framework  is  used  to 
construct  a  solution  that  will  bound  and  clarify  requirements,  functions,  and  physical 
components.  As  constraints  or  limitations  are  reached  or  discovered  within  each  process, 
a  feedback  loop  exists  to  initiate  re-evaluation  of  that  particular  element. 


Figure  8.  Requirements  Mapping  in  SE  Process 
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To  identify  requirements,  the  Distance  Support  capstone  team  analyzed  a 
combination  of  inputs  from  the  stakeholders,  including  past  studies  and  already 
completed  surveys  conducted  by  NSWC  PHD  personnel  in  relation  to  Distance  Support, 
which  was  discussed  in  detail  in  Chapters  I  and  II.  The  team  then  compared  the  system 
requirements  with  the  Distance  Support  policy  and  guidance  published  by  SEA  21  to 
ensure  all  requirements  met  current  Distance  Support  standards.  From  these  inputs,  the 
requirements  for  DAS  were  identified.  A  complete  listing  of  these  requirements  can  be 
found  in  Appendix  A. 

B.  REQUIREMENTS  PARTITION 

Figure  9  shows  the  DAS  requirements.  The  team  used  their  past  experiences  with 
Navy  standard  formats  for  developing  combat  system  requirement  specifications  to  group 
the  requirements  into  three  different  categories.  The  categories  are  defined  as:  1) 
Characteristics,  2)  Design  and  Construction,  and  3)  Component  Level  Requirements.  The 
first  category,  Characteristics,  is  where  the  requirements  are  related  to  system  capability 
and  performance.  The  second  category,  Design  and  Construction,  calls  out  the 
requirements  associated  with  data  accessibility:  data  collection,  data  formatting,  the 
interface  encountered  by  the  user,  and  the  aspects  dealing  with  Information  Assurance 
(IA)  compliance.  The  third  category,  Component  Level  Requirements,  identifies  the 
requirements  for  the  hardware  and  software. 
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Figure  9.  Top  Level  Requirements 

1.  Characteristic  Requirements  (R.1.0) 

The  characteristic  requirements  as  shown  in  Figure  10  define  the  requirements  of 
the  system  based  on  its  performance,  physical  characteristics,  reliability,  maintainability, 
as  well  as  the  environment  conditions  where  the  system  will  be  operated. 


hier  Characteristics 


Project: 


Distance  Support  Data  Aggregation  System 


Organization: 


December  26,  2012 


Figure  10.  Characteristics  Requirements 
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a.  Performance  Requirements  (R.  1.1) 

The  performance  requirements  shown  in  Figure  11  address  the 
requirements  of  the  DAS  based  on  the  primary  functions  that  must  be  executed  in  support 
of  DAS’  mission.  The  requirements  are  measured  in  terms  of  accuracy,  accessibility, 
quality,  and  timeliness.  The  performance  requirements  of  the  DAS  are  categorized  and 
described  as  follows: 

(1)  External  Interface:  The  system  shall  be  capable  of 
interfacing  with  various  other  systems,  databases,  and  data  systems  to  collect  and  provide 
necessary  data  to  perform  all  the  functions. 

(2)  Fleet  Maintenance  Support  Data  and  Metrics:  The  system 
shall  process,  analyze,  and  provide  data  and  metrics  that  will  be  used  to  support  fleet 
maintenance. 

(3)  Logistics  Data:  The  system  shall  process,  analyze,  and 
provide  logistics  data  in  support  of  fleet  maintenance  and  life  cycle  support. 

(4)  Training  Data:  The  system  shall  provide  data  that  reflects 
fleet  training  discrepancies. 

(5)  RMA  Analysis  Data:  The  system  shall  be  able  to  process, 
analyze  and  provide  RMA  data  with  respect  to  combat  system  performance. 

(6)  Reports:  The  system  shall  be  designed  to  allow  the  user  to 
generate,  save,  and  print  the  reports  to  a  file  with  the  standard  format  such  as  Acrobat 
Portable  Document  Format  (PDF)  or  Microsoft®  Office  products  (i.e.,  Word  or  Excel) 
from  the  web  pages  where  the  data  can  be  selected  and  filtered  by  user  defined 
characteristics. 
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hier  Performance 


Project: 

Distance  Support  Data  Aggregation  System 

Organization: 

NSWC  PHD 

Date: 

December  26,  2012 

Figure  11.  Performance  Requirements 
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b.  Physical  Characteristics  (R.1.2) 

This  group  of  requirements  was  established  to  ensure  the  DAS  will  not 
exceed  the  physical  capabilities  of  the  host  platform.  Among  these  characteristics,  the 
following  are  deemed  most  critical  to  a  successful  integration:  human  system  integration, 
and  physical  size  (dimensions). 

The  physical  characteristics  requirements,  as  shown  in  Figure  12,  were 
decomposed  to  the  following  listed  requirements: 

(1)  Human  System  Integration:  The  system  shall  be  designed 
and  tested  to  satisfy  human  engineering  design  requirements  and  standards  included  in 
but  not  limited  to  the  latest  version  of  DoD  Design  Criteria  Standard  Human  Engineering, 
U.S.  Army  Aviation  and  Missile  Command,  MIL-STD-1472F,  1999. 

(2)  Size:  The  physical  size  of  the  DAS  shall  conform  to  the  lab 
space  available  at  NSWC  PHD.  The  major  components  that  are  selected  for  the  system 
shall  support  rack  mount  installation. 


Figure  12.  Physical  Characteristics 
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c.  Reliability  (R.1.3) 

The  reliability  requirement  establishes  the  minimum  mean  time  between 
failures  that  the  system  must  achieve  in  response  to  internal  system  failures  (i.e.,  faults, 
component  failures).  The  Key  Performance  Parameters  (KPP)  subsection,  discussed  later 
in  this  report,  provides  additional  information,  including  the  threshold  value  that  must  be 
achieved. 


d.  Maintainability  (R.1.4) 

This  requirement  calls  out  the  mean  time  to  restore  the  system,  including 
hardware  and  software,  from  a  system  reload  and  from  routine  maintenance. 

e.  Environment  Condition  (R.1.5) 

This  requirement  refers  to  the  location  and  space  with  respect  to 
temperature  where  the  system  will  be  operated  under  specific  environment  conditions. 

2.  Design  and  Construction  Requirements  (R.2.0) 

The  design  and  construction  requirements  depicted  in  Figure  13  comprise  the 
requirements  for  data  collection,  data  reporting,  Navy  Marine  Corps  Intranet  (NMCI) 
compliance,  and  print  and  save. 


Figure  13.  Design  and  Construction  Requirements 
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a.  Data  Collection  (R.2.1) 

The  system  shall  be  designed  to  collect  data  either  by  manually  entered 
data  from  the  user  interface  or  automatically  from  an  external  file  or  database. 

b.  Data  Reporting  ( R.2.2 ) 

The  system  shall  be  designed  to  generate  and  display  data  as  specified  in 
the  performance  section  (R.1.1). 

c.  NMCI  Compliance  (R.2.3) 

The  system  shall  be  designed  to  comply  with  NMCI. 

d.  Print  and  Save  (R.2.4) 

The  system  shall  have  the  capability  to  Print  and  Save  the  data. 

3.  Components  Level  Requirements  (R.3.0) 

The  component  level  requirements  identified  the  system  design  requirements  with 
respect  to  the  hardware  and  software.  Since  the  primary  sources  of  information  for  the 
DAS  reside  on  existing  computer  network  devices  and  servers,  the  DAS  must  also 
contain  components  that  can  interface  with  these  servers  and  retrieve  necessary 
information.  Therefore,  at  a  minimum,  the  two  primary  components  of  the  DAS  include 
both  hardware  and  software  as  depicted  in  Figure  14.  Figure  14  shows  the  hierarchy  of 
Component  Level  Requirements  that  were  refined  into  two  different  categories,  hardware 
components  and  software  components. 
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Figure  14.  Components  Level  Requirements 

a.  Hardware  (R.3.1) 

The  system  shall  use  Commercial  Off-the-Shelf  (COTS)  hardware  that  is 
capable  of  supporting  the  design  characteristics  defined  in  the  characteristics  section 

(RIO)- 

b.  Software  (R.3.2) 

The  system  shall  use  COTS  software  that  is  capable  of  supporting  the 
design  characteristics  defined  in  the  characteristics  section  (R.  1 .0) 

C.  FUNCTIONAL  REQUIREMENTS 

The  team  elected  to  utilize  Vitech’s  CORE®  software  suite  to  analyze 
requirements.  CORE®  is  a  tool  specifically  designed  for  SE,  facilitating  simple  steps 
from  requirement  analysis  to  architecture  design  and  then  to  testing.  After  defining  the 
stakeholder  requirements  and  inputting  them  into  CORE®,  the  team  moved  on  to  define 
the  system  functions  necessary  to  satisfy  the  requirements.  Most  functions  were  defined 
using  past  studies,  surveys,  benchmarking,  and  team  member’s  personal  experience  with 
the  available  tools  for  data  aggregation.  The  team  drafted  a  list  of  needs,  which  was 
reviewed  and  updated  through  several  revisions  by  stakeholders  in  order  to  develop  the 
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final  list  of  functions,  which  can  be  found  in  Appendix  B.  This  final  list  was  entered  into 
CORE®  and  defined  in  a  hierarchal  format  that  allowed  top  functions  to  be  decomposed 
into  more  detailed  lower  level  functions.  A  total  of  four  levels  of  decomposition  were 
created  in  CORE®. 

Figure  15  provides  a  high  level  view  of  the  functions  required  to  aggregate  data 
and  how  the  flow  of  data  is  passed  from  one  function  to  the  other.  After  the  data  is 
received  by  DAS,  it  is  processed,  analyzed,  and  reported.  The  output  data  is  displayed  to 
the  end  user  in  the  format  requested.  The  end  user  can  save,  print  or  generate  a  report  to 
support  the  issue  they  are  tracking. 


Figure  15.  System  Function  Flow  Diagram 
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D.  INPUT-OUTPUT  REQUIREMENTS 

The  input  requirements  of  DAS  include  the  user  and/or  fleet  input  data  and  the 
fleet  maintenance  data  infrastructure.  This  process  is  illustrated  in  Figure  16.  The  output 
requirements  include  numerous  displays  and  reports.  Reports  include:  1)  system  status 
reports,  2)  system  RMA  reports,  3)  system  assessment  reports,  4)  logistics  reports,  5) 
historical  system  performance  reports,  and  6)  historical  maintenance  reports.  In  addition 
to  reports,  the  output  requirements  also  include:  1)  training  data,  2)  system,  ship,  and 
Point  of  Contact  (POC)  information,  3)  system  performance  trend  data,  4)  RMA  data,  5) 
maintenance  cost  data,  6)  logistic  data,  7)  logistics  cost  data,  and  8)  Question  and  Answer 
(Q&A)  data.  At  the  user  interface,  the  system  will  display  troubleshooting  procedures  for 
the  following:  1)  common  equipment  failures,  2)  corrective  maintenance  data,  3) 
technical  support  information,  4)  logistics  data,  5)  RMA  and  trend  data,  6)  fleet  training 
deficiency  data,  7)  fleet  readiness  data,  and  8)  fleet  costs. 
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Network  Connection 


ReetData 

Fleet  Support  Infrastructure  Data 
User  Input  Data 


Figure  16.  Provide  Data  Aggregation  Capability  (IDEFO) 
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Figure  17  provides  an  enlarged  excerpt  taken  from  Figure  16.  It  shows  a  focused  graphic 
of  the  Obtain  Data  and  Process  Data  blocks  in  the  DAS’  IDEFO. 


Figure  17.  Enlarged  Excerpt  Taken  From  DAS  IDEFO 

E.  FUNCTIONAL  ANALYSIS  AND  ALLOCATION 

As  defined  in  System  Engineering  and  Analysis, 

The  functional  analysis  is  an  iterative  process  of  translating  system 
requirements  into  detailed  design  criteria  and  the  subsequent  identification 
of  the  resources  required  for  system  operation  and  support.  It  includes 
breaking  requirements  at  the  system  level  down  to  subsystem,  and  as  far 
down  the  hierarchical  structure  as  necessary  to  identify  input  design 
criteria  and/or  constraint  for  the  various  elements  of  the  system.  The 
purpose  is  to  develop  the  top  level  system  architecture,  which  deals  with 
both  ‘requirements’  and  structure  (Blanchard  and  Fabrycky  2011,  86). 

DAS  development  began  with  a  physical  context  diagram  of  the  initial  system  concept  as 

shown  in  Figure  18.  The  DAS  is  highlighted  by  the  dotted  box.  The  input  and  output 

interfaces  to  and  from  DAS  are  covered  later  in  this  section.  This  context  diagram  created 

a  system  boundary  which  helped  to  scope  and  bound  the  project.  The  context  diagram 
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also  describes  the  external  interfaces  and  the  relationships  between  the  developed  system 
and  the  external  systems.  Once  finalized,  the  context  diagram  provided  the  foundation  for 
the  DAS  architecture. 


Figure  18.  Physical  Context  Diagram 


1.  Functional  Decomposition  and  Hierarchy 

The  functional  hierarchy  describes  the  high  level  functions  needed  to  meet  the 
system  requirements.  These  high  level  functions  were  then  further  decomposed  in  an 
iterative  process  to  determine  lower  level  functions  to  a  level  that  was  sufficient  to  define 
the  system  architecture.  The  functional  hierarchy  that  was  determined  after  completing 
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the  requirements  analysis  is  shown  in  Figure  19.  The  second  level  system  functions  are: 
1)  provide  external  interface,  2)  obtain  data,  3)  process  data,  4)  analyze  data,  5)  report 
data,  6)  display  data,  and  7)  print  and  save  data.  More  detailed  functions  are  further 
defined  at  the  third  level  as  indicated  in  Figure  19. 
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Figure  19.  Functional  Hierarchy 
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2.  System  Functions  Description 

The  high  level  system  function  descriptions  are  provided  in  Appendix  B.  These 
high  level  system  functions  are  contained  within  the  first,  second,  and  third  levels  of 
decomposition  as  described  in  Figure  19.  The  team  recognized  that  additional  levels 
beyond  the  third  level  are  necessary  to  adequately  describe  the  system  architecture 
however,  due  to  time  constraints  the  project  was  limited  to  only  decomposing  down  to 
four  levels.  Functional  descriptions  beyond  the  third  level  are  contained  within  the 
CORE®  model  that  was  used  to  develop  this  project. 

3.  Functional  Allocation  Matrix 

a.  Mapping  requirements  to  system  functions 

The  next  step  in  the  architectural  development  phase  was  to  create  an 
allocation  matrix  that  mapped  requirements  to  system  functions  and  system  functions  to 
physical  components.  The  allocation  matrix  was  an  effective  tool  because  it  provided 
traceability  between  the  requirements  to  functions  and  then  functions  to  physical 
components  of  the  DAS.  Traceability  was  an  important  consideration  for  system 
integration  to  ensure  each  requirement  was  allocated  to  at  least  one  function  and  all  the 
functions  included  in  the  architecture  were  allocated  to  the  physical  components.  It  is  an 
important  corollary  that  the  aforementioned  logic  applies  in  reverse  and  all  physical 
components  directly  map  to  functions  required  by  the  stakeholders. 

The  complete  functional  allocation  matrix  can  be  found  in  Appendix  B. 
Figure  20  provides  an  excerpt  from  the  matrix  due  to  size  constraints.  A  dot  (•)  is  placed 
in  the  column  and  row  intersection  where  a  desired  function  is  filled  by  its  corresponding 
requirements  and  physical  components. 
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Figure  20.  Mapping  Requirements  to  System  Functions 
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b.  Mapping  system  functions  to  system  components 

The  functional  allocation  matrix  was  created  using  the  functions  and  the 
physical  components  designed  to  perform  those  functions  of  DAS.  The  team  did  not  use 
specific  physical  components  to  avoid  limiting  the  type  of  technology  that  could  be 
integrated.  The  complete  matrix  shows  that  each  function  was  mapped  to  a  physical 
component.  In  this  manner,  the  allocation  matrix  provides  traceability  between  system 
functions  and  physical  components. 

4.  System  Enhanced  Functional  Flow  Block  Diagrams 

Accomplishment  of  the  functional  analysis  is  facilitated  through  the  use  of 
Enhanced  Functional  Flow  Block  Diagrams  (EFFBDs).  The  EFFBD  in  Figure  21 
provides  a  flow  block  diagram  of  high  level  system  functions  derived  from  the  system 
requirements.  The  main  functions  of  DAS  are  defined  as:  1)  provide  external  interface,  2) 
obtain  data,  3)  process  data,  4)  analyze  data,  5)  report  data,  6)  display  data,  and  7)  print 
and  save  data. 
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a. 


External  Enhanced  Function  Flow  Block  Diagram 


The  external  function  flow  block  diagram,  shown  in  Figure  22,  was 
designed  using  CORE®  was  used  by  the  team  to  help  identify  the  external  system 
interfaces.  The  DAS  will  need  to  interface  with  multiple  sources  and  therefore  it  is 
critical  to  identify  and  understand  the  external  functions  necessary  to  ensure  the  quality 
of  the  data  targeted  for  aggregation  and  reporting.  The  high  level  external  functions 
identified  by  the  stakeholders  include:  1)  perform  fleet  support  infrastructure  database 
functions,  2)  perform  NSWC  PHD  Distance  Support  web  page  functions,  3)  perform 
stakeholder  functions,  and  4)  ultimately  perform  ship  functions.  Figure  22  depicts  the 
flow  of  information  and  functional  relationship  from  one  source  to  the  next.  The  high 
level  controls  for  each  function  are  shown  at  the  top.  These  controls  include:  1)  by 
request,  2)  periodic,  3)  manual,  4)  Internet  access,  5)  network  interface,  6)  automatic,  and 
7)  as  needed.  Identifying  the  controls  was  necessary  to  identify  the  access  points  required 
to  execute  functions  and  sub  functions.  More  specifically,  to  ensure  the  flow  of  data  to 
and  from  the  DAS  was  accurate  and  complete,  and  to  ensure  the  system  interfaces  were 
designed  accordingly. 
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Figure  22.  External  Enhanced  Function  Flow  Block  Diagram 


58 


b.  Provide  External  Interface  Functions  Enhanced  Flow  Block 
Diagram  (F.1.0) 

Figure  23  provides  more  detail  in  regards  to  the  first  DAS  function, 
execute  system  interface  (F.1.0).  The  diagram  in  Figure  23  shows  the  controls  and  the 
specific  data  processed  by  this  function.  To  execute  the  system  interface  function,  system 
users  and  the  fleet  support  infrastructure  database  will  process  data  via  the  network 
interface  and  Internet  access  which  are  highlighted  in  green  color  in  Figure  23.  The 
network  interface  and  Internet  access  are  considered  the  controls  for  the  external  interface 
function.  The  data  processed  during  this  function  will  include:  1)  fleet  logistics  data,  2) 
fleet  technical  assist  data,  3)  ships,  system,  and  point  of  contact  information,  4)  fleet 
RMA  data,  and  5)  fleet  3M  data.  A  network  provider  is  also  necessary  to  perform  this 
function.  The  network  provider  will  be  responsible  for  establishing  the  physical 
connection  between  the  DAS  and  the  external  systems. 


Figure  23.  Provide  External  Interface  Function  (F.1.0) 
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c.  Obtain  Data  Functions  Enhanced  Flow  Block  Diagram  (F.2. 0) 

Figure  24  is  also  from  the  CORE®  model  and  provides  details  in  regards  to  the 
second  DAS  function,  obtain  data  function  (F.2.0).  This  function  is  further  decomposed 
in  Figure  24  to  the  next  lower  level  to  further  describe  the  controls  and  information 
processed  by  this  function.  Data  will  need  to  be  obtained  from  multiple  sources  which 
include:  1)  data  from  user  inputs,  2)  data  from  the  fleet,  and  3)  data  from  the  fleet  support 
infrastructure.  The  controls  for  these  functions  include:  1)  manual,  2)  by  request,  3) 
periodic,  and  4)  automatic.  In  addition  to  capturing  data  from  multiple  sources,  the  obtain 
data  function  will  also  be  required  to  convert  multiple  data  formats  to  a  common  format 
so  that  the  data  can  be  processed  without  loss  of  data.  This  is  a  critical  component  of 
DAS,  to  ensure  the  quality  of  the  data  satisfies  stakeholder  needs. 


Figure  24. 


Obtain  Data  Function  (F.2.0) 
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d. 


Process  Data  Enhanced  Function  Flow  Block  Diagram  (F.3.0) 


Figure  25  is  another  CORE®  model  that  describes  the  process  data 
function  (F.3.0).  Figure  25  further  decomposes  this  function  to  five  sub  functions:  1) 
process  general  information,  2)  process  maintenance  data,  3)  process  logistics  data,  4) 
process  training  data,  and  5)  process  RMA  data.  These  sub  functions  were  determined  to 
be  necessary  for  DAS  to  produce  the  desired  products  and  information.  These  sub 
functions  were  further  decomposed  in  CORE®  and  can  be  found  in  Appendix  B.  The 
controls  for  this  function  include:  1)  by  request,  2)  automatic,  3)  manual,  and  4)  periodic. 
The  inputs  to  these  sub  functions  come  directly  from  the  obtain  data  function.  In  general, 
the  process  data  function  involves  data  filtering,  data  consolidation,  data  organizing,  data 
comparing,  and  data  categorizing  all  of  which  are  necessary  for  effective  analyzing  and 
reporting  which  are  additional  functions  to  be  performed  in  DAS. 
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Figure  25.  Process  Data  Function  (F.3.0) 
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e.  Analyze  Data  Enhanced  Function  Flow  Block  Diagram  (F.4.0) 

The  analyze  data  function  (F.4.0),  which  is  necessary  for  the  ISEAs  to 
monitor  the  effectiveness  of  system  maintenance,  logistics  support,  training,  and 
reliability  in  order  to  enable  continuous  system  improvements,  as  well  as  to  facilitate  self- 
help  capabilities  for  the  fleet,  is  decomposed  in  CORE®  to  four  sub  functions  as  shown 
in  Figure  26.  These  sub  functions  include:  1)  analyze  maintenance  data,  2)  conduct 
system  performance  trends,  3)  compute  system  Ao  and  Inherent  Availability  (Ai),  and  4) 
conduct  cost  analysis.  These  sub  functions  are  further  decomposed  in  CORE®  and 
included  in  Appendix  B.  The  four  sub  functions  are  necessary  for  DAS  to  fully  analyze 
the  formatted  data  and  produce  useful  information  for  the  stakeholders.  The  inputs  from 
the  process  data  function  include:  1)  maintenance  data,  2)  reliability  data,  3)  logistics 
data,  and  4)  training  data.  The  information  that  is  produced  by  the  analyze  data  function 
includes:  1)  technical  assistance  metrics,  2)  CASREP  metrics,  and  3)  system  and 
component  failure  metrics. 
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Figure  26.  Analyze  Data  Function  (F.4.0) 
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f.  Report  Data  Function  Flow  Block  Diagram  (F.5. 0) 

The  outputs  of  the  analyze  data  function  (F.4.0)  are  fed  directly  into  the 
report  data  function  (F.5.0)  as  shown  in  the  CORE®  model  in  Figure  27.  The  report  data 
function  was  decomposed  to  four  sub  functions  that  include:  1)  generate  system 
assessment  reports,  2)  generate  logistics  reports,  3)  generate  system  status  reports,  and  4) 
generate  system  RMA  reports.  These  sub  functions  are  further  decomposed  in  CORE® 
and  included  in  Appendix  B.  As  with  the  previous  functions,  the  controls  for  this  function 
include:  1)  by  request,  2)  automatic,  and  3)  manual.  The  reporting  data  function  (F.5.0) 
prepares  the  data  for  the  display  data  function  (F.6.0)  and  satisfies  the  need  to  provide 
stakeholders  with  a  tool  to  review  and  share  results  from  the  data  analysis  process. 
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Figure  27.  Report  Data  Function  (F.5.0) 
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Display  Data  Enhanced  Function  Flow  Block  Diagram  (F.6.0) 


g- 

Figure  28  is  another  CORE®  model  depicting  the  display  data  function 
(F.6.0)  at  a  high  level.  This  function  was  decomposed  into  five  sub  functions  including: 
1)  display  fleet  support  information,  2)  display  historical  fleet  data,  3)  display  corrective 
maintenance,  4)  display  logistics  data,  and  5)  display  RMA  analysis  data.  Further 
decomposition  into  lower  functions  was  performed  in  CORE®  and  included  in  Appendix 
B.  The  controls  for  this  function  include:  1)  automatic,  2)  by  request,  3)  manual,  and  4) 
periodic.  As  previously  mentioned,  controls  were  necessary  to  identify  access  for 
executing  sub  functions.  Figure  28  also  shows  examples  of  some  of  the  information  that 
is  aggregated  to  produce  the  various  displays.  The  aggregated  data  as  inputs  to  the  sub 
functions  includes  items  such  as:  1)  system  configuration,  2)  SME  POCs,  3)  highest  LRU 
failures,  4)  CASREP  metrics,  and  5)  technical  assistance  metrics.  The  various  displays 
needed  from  the  report  data  function  include  such  things  as  logistics  data,  RMA  data, 
training  data,  and  cost  data.  The  display  data  function  and  related  sub  functions  are 
necessary  to  visually  produce  useful  self-help  and  trend  analysis  information  for  the 
stakeholders. 
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Figure  28.  Display  Data  Function  (F6.0) 
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h.  Print  and  Save  Function  Flow  Block  Diagram  (F.  7. 0) 

Figure  29  shows  the  CORE®  model  that  describes  the  print  and  save 
function  (F.7.0).  Further  decomposition  into  lower  sub  functions  was  performed  in 
CORE®  and  included  in  Appendix  B.  The  control  for  this  function  is  limited  to  “by 
request.”  The  “by  request”  control  was  selected  to  ensure  that  unnecessary  print  and  save 
actions  would  be  avoided.  Figure  29  also  shows  examples  of  some  of  the  information  that 
would  typically  be  saved  and  printed.  The  aggregated  data  that  stakeholders  indicated 
would  typically  be  printed  and  saved  includes  1)  historical  maintenance  data,  2)  logistics 
reports,  3)  system  RMA  reports,  4)  system  assessment  reports,  and  5)  historical  system 
performance  trend  data. 


Figure  29.  Print  &  Save  Data  Function  (F.7.0) 
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5. 


External  Functions 


Figure  30  shows  the  interface  between  the  external  functions  and  DAS.  In  this 
diagram,  the  DAS  receives  input  data  from  both  the  fleet  support  infrastructure  database 
and  ship  functions,  and  it  outputs  data  that  is  sent  to  NSWC  PHD  Distance  Support  web 
page  functions  for  report  and  display.  The  data  will  be  requested  and  accessed  by  the 
stakeholder  via  stakeholder  functions. 
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Figure  30.  Perform  Physical  Context  Functions  (IDEFO) 
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The  diagram  in  Figure  3 1  provides  a  high  level  view  of  the  functions  required  to 
aggregate  data  and  how  the  data  is  passed  from  one  function  to  the  other.  In  short,  after 
the  data  is  received,  it  is  processed,  analyzed,  reported,  and  then  displayed  to  the  users. 
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Figure  31.  High  Level  System  Functions  IDEFO  Diagram 
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F.  EVALUATION  MEASURES  AND  METRICS 

Based  on  stakeholder  requirements,  the  DAS  would  need  to  meet  the  following 
performance  requirements: 

•  Data  Collection  Process  -  the  ability  to  connect  and  capture  available 
information  from  multiple  sources,  including  the  ability  to  overcome 
incompatibility  of  sources  (i.e.,  interoperability) 

•  Data  Quality  -  the  ability  to  display  accurate,  useful,  reliable,  and 
complete  data,  including  historical  troubleshooting  experience  data,  repair 
procedures  data,  and  historical  technical  assist  experience  data 

•  Accessibility  -  the  ability  to  display  information  when  needed  including 
the  accessibility  of  ship-to-shore  connectivity  and  access  time  of  the  initial 
request  to  receipt  of  information 

•  Data  Organizing  and  Processing  -  the  ability  to  organize  data  for  effective 
analysis. 

Based  upon  the  above  performance  measures  and  assistance  from  stakeholders, 
the  team  defined  the  following  metrics  for  the  system: 

•  Metrics  related  to  data  quality 

•  Accuracy,  usefulness,  reliability,  and  completeness 

•  Age  of  data  (how  often  updated) 

•  Metrics  related  to  DAS 

•  Availability  of  data  (accessibility) 

•  Data  processing  (how  effective  at  combining) 

•  Time  of  report  generation. 

Since  the  requirements  discussed  in  Chapter  II  are  very  general,  the  team  further 
defined  them  in  order  to  derive  metrics  that  contained  measurable  attributes.  Table  3 
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summarizes  the  metrics  that  were  defined  by  the  stakeholders  as  the  key  metrics  to  be 
used  in  development  of  the  system  architecture.  As  discussed  previously,  the  stakeholders 
indicated  that  the  DAS  must  be  effective  at  aggregating  available  information  so  metrics 
related  to  the  quality  of  the  information  are  important  for  ensuring  that  the  information 
will  be  beneficial. 


Requirement 

Metrics 

Objective 

Threshold 

Accuracy  (Ability  to  provide  correct  and 
consistent  results) 

Probability  of  accuracy  = 
99.5%  (5  discrepancies  per 
1000  data  requests) 

Probability  of  accuracy  = 
99%  (10  discrepancies  per 
1000  data  requests) 

Accessibility  (Ability  to  access  data  via  Port 
Hueneme  Division  (PHD)  web  page) 

2  seconds  (*) 

1 0  seconds 

Adaptability  (Ability  to  interface  with  multiple 
application/  database) 

All  databases  that  can  be 
accessed  defined  in  the 
requirements 

All  databases  that  can  be 
accessed  defined  in  the 
requirements 

Flexibility  (Easily  to  learn  and  use) 

Non-Proprietary  Software 
&  Compliant  with 
Department  of  Defense 
(DoD)  Standard 

Compliant  with  DoD 
Standard 

Human  Factors  (Easily  to  learn  and  use) 

Time  for  new  user  to 
obtain  data  t  =  3  minutes, 
return  user  t  =  2  minutes 

Time  for  new  user  to 
obtain  data  t  =  5  minutes, 
return  user  t  =  3  minutes 

Maintainability  (Ability  to  fault  detect  and  fault 
isolate) 

Mean  Time  To  Repair 
(MTTR)  <  1  hour 

MTTR  <  2  hours 

Reliability  (Reliable  to  sustain  operation) 

1  failure  per  12  months 

1  failure  per  9  months 

Availability  (Operational  Availability  (A0)) 

A0  >  99.9% 

A0  >  99% 

Time  to  Generate  Report  (System) 

Data  rate  t  =  1 5  seconds 
per  1  megabyte  (MB) 

Data  rate  t  =  20  seconds 
per  1  MB 

Completeness 

Display  all  available  data 
that  the  system  can 
generate  from  existing 
database 

Display  all  available  data 
that  the  system  can 
generate  from  existing 
database 

Timeliness  (Frequency  of  data  update) 

Upon  request 

Daily 

Table  3.  Requirement  Metrics 


These  metrics  were  used  as  evaluation  measures  in  the  AoA  to  help  determine 
which  alternative  would  best  meet  DAS  requirements.  In  order  to  do  so,  the  team  split  the 
metrics  listed  in  Table  3  into  two  groups.  The  first  group  is  the  metrics  related  to  data 
quality,  which  include  accuracy,  usefulness,  reliability,  completeness,  and  so  forth,  as 
well  as  the  age  of  data  (how  often  updated).  The  second  group  is  the  metrics  related  to 
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DAS,  which  include  availability  of  data  (accessibility),  data  processing  (how  effective  at 
combining)  and  time  of  report  generation. 

The  team  decided  that  it  was  necessary  to  determine  to  what  extent  each 
alternative  in  the  AoA  met  these  metrics.  Thus,  a  scale  from  zero  (0)  to  ten  (10)  was 
implemented  to  rate  each  alternative  on  how  well  it  performed  with  respect  to  the  metric, 
where  a  score  of  zero  implied  the  alternative  did  not  satisfy  the  metric  at  all  and  a  score 
of  ten  meant  the  alternative  satisfied  the  threshold.  Table  4  summarizes  the  metrics 
related  to  data  quality  and  Table  5  summarizes  the  metrics  related  to  DAS. 


Quality  Type 

Question 

Metric 

Accuracy 

Does  the  data  reflect  a  verifiable 
source  in  a  precise  way?  (Is  the  data 
correct?) 

Scale  0-10,  10  =  best 

Completeness 

Is  all  necessary  data  present? 

Scale  0-10,  10  =  best 

Consistency 

Are  there  any  contradictions  between 
data  sets? 

Number  of  contradictions 
between  data  sets  / 

Number  of  Data  sets 

Data  processing 

How  effective  is  system  at  combining 
data? 

Scale  0-10,  10  =  best 

Relevancy 

Is  the  data  applicable  and  helpful  for 
the  task  at  hand? 

Scale  0-10,  10  =  best 

Reliability 

Does  the  obtained  answers  conform 
the  expected  answers? 

Number  of  answers  that 
conform  the  expected 
answers  /  Total  number  of 

answers 

Timeliness 

How  often  is  the  data  updated? 

Number  of  updates  per  day 

Usefulness 

Is  there  any  difference  in  having  or 
not  having  the  data  for  the  user? 

Scale  0-10,  10  =  best 

Table  4.  Metrics  Related  to  Data  Quality 
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Characteristic 

Definition 

Metric 

Accessibility 

The  time  it  takes  to  access  the  system 
(availability  of  data). 

Access  Time  (t  =  seconds) 

Adaptability 

Complexity  scale  to  interface  with 
other  systems. 

Scale  0-10,  10  =  least 
complex 

Flexibility 

Ease  of  modification. 

Scale  0-10,  10  =  best 

Data  Processing 

System  effectiveness  of  combining 
the  data. 

Scale  0-10,  10  =  best 

Human  Factors 

User  friendliness,  degree  of 
automation,  displays,  controls, 
feedback,  and  so  forth. 

Scale  0-10,  10  =  best 

Maintainability 

The  ease  with  which  the  system  can 
be  maintained. 

MTTR  (t  =  minutes) 

Mean  Maintenance 
Downtime  (MMD)  (t 
=minutes) 

Reliability 

The  ability  of  the  system  to  perform 
and  maintain  its  function  in  routine 
and  unexpected  circumstances. 

Operational  Availability 
(Ao),  Mean  Time  Between 
Failures  (MTBF)  (t  = 
hours) 

Time  of  Report 
Generation 

The  time  it  takes  from  the  request  of  a 
new  report  to  the  point  it  is  available 
for  use. 

t  =  seconds 

Table  5.  Metrics  Related  to  DAS 


G.  ANALYSIS  OF  ALTERNATIVES  (AOA) 

To  find  an  effective  solution  for  aggregating  data,  a  structured  approach,  shown  in 
Figure  32,  was  utilized.  First,  the  details  of  DAS  functions  were  clearly  defined  and 
entered  into  CORE®.  Once  the  functions  were  defined,  alternative  solutions  that 
consisted  of  new,  experimental,  and  existing  systems  were  identified.  The  team  worked 
with  stakeholders  to  compare,  prioritize,  and  organize  the  stakeholder  requirements  using 
a  swing  weight  model.  The  stakeholder  preferences  obtained  by  the  normalized  weights 
produced  by  the  swing  weight  model  were  then  used  to  compare,  or  map,  technical 
characteristics  to  requirements,  functions  to  technical  characteristics,  and  alternatives  to 
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functions  using  a  Quality  Function  Deployment  (QFD)  House  of  Quality  (HOQ)  model. 
A  gap  analysis  was  then  conducted  to  identify  the  functional  gaps  of  each  of  the  existing 
systems.  Finally,  a  cost  benefit  analysis  was  performed  to  compare  alternatives  and  select 
the  most  affordable  alternative  that  provided  the  best  solution.  Details  of  each  step  in  this 
approach  are  discussed  in  the  paragraphs  that  follow. 


Figure  32.  AoA  Approach 
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1.  Determining  Alternative  Solutions 

To  identify  alternative  solutions,  the  team  performed  a  number  of  online  searches 
and  brain  storming  sessions.  The  team  also  utilized  the  information  gathered  to  eliminate 
infeasible  solutions.  Thus,  the  team  generated  the  following  alternatives  to  satisfy  DAS 
and  provide  reasoning  to  why  certain  alternatives  were  eliminated: 

•  Alternative  1.  Do  nothing  (maintain  the  status  quo).  Alternative  1, 
to  do  nothing,  was  eliminated  because  stakeholders  indicated  that 
to  do  nothing  is  unacceptable  since  the  need  for  improved  Distance 
Support  is  growing  every  day.  The  development  of  DAS  has 
significant  interest  at  the  highest  levels  within  the  NAVSEA 
command. 

•  Alternative  2.  Modify  Sailor  training  curriculum  and  teach  Sailors 
how  to  access  data  from  available  sources.  Alternative  2,  to  modify 
Sailor  training  curriculum,  was  also  eliminated  due  to  feedback 
from  stakeholders  that  showed  that  the  increasing  burden  on 
Sailors  to  perform  their  own  research  is  not  effective.  Sailors  just 
do  not  have  the  time  to  conduct  their  own  research.  Plus  with  this 
alternative,  there  was  the  possibility  of  the  system  having  a  poor 
response  time,  limited  response  quality  control,  limited  automated 
data  collection  and  reporting  capability,  and  thus  would  not  meet 
many  of  the  system  requirements. 

•  Alternative  3.  Perform  manual  data  aggregation  by  increasing  the 
number  of  shore  support  personnel.  Alternative  3,  to  perform 
manual  data  aggregation,  was  also  eliminated  because  increasing 
the  shore  based  work  force  is  not  possible  in  a  fiscally  constrained 
environment.  Additionally,  this  alternative  would  require 
insurmountable  life  cycle  costs  due  to  high  labor  costs,  large  time 
delays  between  data  requests  and  deliveries  since  everything  would 
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be  done  manually,  and  not  meet  all  system  requirements.  Thus,  this 
option  is  simply  not  feasible  at  this  time  and  not  cost  effective. 

•  Alternative  4.  Develop  a  “self-help”  styled  forum  in  which  fleet 
activities  can  ask  the  combat  systems  community  for  solutions  to 
their  issues.  Experts  or  other  combat  system  personnel  can  search 
and  answer  questions.  Alternative  4  was  eliminated  because 
although  it  offers  limited  life  cycle  costs,  after  initial  development 
costs,  it  presents  a  high  possibility  of  poor  response  time  and 
limited  data  collection  and  reporting  capability.  Furthermore,  this 
alternative  does  not  offer  the  required  data  display  capability, 
making  it  un-useful  for  shore  based  activities,  and  overall  does  not 
meet  all  system  requirements. 

•  Alternative  5.  Develop  a  new  database  and/or  website  that  would 
collect,  combine,  and  display  data. 

•  Alternative  6.  Modify  an  existing  database  and/or  website. 

Alternatives  5  and  6  were  determined  to  be  feasible  based  on  numerous 
discussions  with  stakeholders  and  were  thus  selected  for  further  analysis.  Alternative  5, 
developing  a  brand  new  system,  and  Alternative  6,  modifying  an  existing  system,  could 
meet  every  requirement  and  customer  need  if  cost  and  time  were  not  factors.  Thus,  it  was 
determined  that  a  cost  and  risk  analysis  should  be  conducted  to  compare  these 
alternatives  and  are  discussed  later  in  this  chapter.  These  analyses  would  determine  the 
cost,  schedule,  and  risk  drivers  that  would  impact  the  development  of  the  system.  Before 
these  analyses  could  be  conducted,  an  existing  system  for  Alternative  6  had  to  be  chosen. 

2.  Identifying  Alternative  Existing  Systems  (Alternative  6) 

The  team  researched  existing  systems  within  the  Navy  and  outside  the  Navy, 
including  commercial  systems  that  could  be  used  as  a  model  for  DAS.  Numerous  systems 
were  identified  to  possess  some  or  most  of  the  functions  required  for  the  system.  In  order 
to  ensure  that  a  solution  was  selected  that  met  the  requirements  and  executed  the 
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important  system  functions;  the  alternative  existing  systems  were  evaluated.  Table  6  lists 
the  acceptable  systems  that  were  identified  for  further  analysis. 


Acronym 

Name 

Host  Organization 

ACSRMS 

Aegis  Combat  System 
Reliability  Maintainability  and 
Supportability  Database 

Naval  Surface  Warfare  Center 
,  Port  Hueneme  Division 
(NSWC  PHD) 

ADA 

Albridge  Data  Aggregation 
(Financial) 

Commercial 

AIDA 

Adaptive  Independent  Data 
Application 

University  of  Virginia 

CIM 

Command  Issue  Management 

NSWC  PHD 

DTIC 

Defense  Technology 

Information  Center 

Assistant  Secretary  of  Defense 
for  Research  and  Engineering 
(ASD  (R&E)) 

ESDS 

Engineering  and  Supportability 
Decision  System 

NSWC  PHD 

GDSC  Remedy 

Global  Distance  Support 

Center  Remedy 

Fleet  and  Industrial  Supply 
Center  Norfolk/San  Diego 
(FISC  NF/SD) 

MFOM 

Maintenance  Figure  of  Merit 

Commander,  U.S.  Fleet  Forces 
Command  (CFFC) 

MRDB 

Material  Readiness  Database 

Naval  Surface  Warfare  Center 
(NSWC)  Corona 

NDE-NM 

Navy  Data  Environment-Navy 
Modernization 

CFFC 

NSLC 3M 

NAVSEA  Logistics  Center  - 
Maintenance  and  Material 
Management 

Naval  Supply  Systems 
Command  (NAYSUP) 
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Acronym 

Name 

Host  Organization 

NANOOS  VS 

Northwest  Associate  of 

Network  Ocean  Observing 
System  Visualization  System 

State  of  Washington 

ORTSTARS 

Operational  Readiness  Test 
System  Tech  Assist  Remote 
Support 

NSWC  PHD 

RDAM 

Regional  Data  Archiving  and 
Management 

State  of  Illinois 

S2E 

Sailor  To  Engineer 

NSWC  PHD 

VAMOSC 

Visibility  and  Management  of 
Operating  and  Support  Costs 

CFFC 

Table  6.  Alternative  Existing  Systems 


a.  Mapping  Alternatives  to  Functions 

The  team  was  able  to  put  together  a  rather  extensive  list  of  existing 
systems  that  could  potentially  be  modified  to  meet  the  DAS  requirements,  so  the  systems 
were  further  analyzed  in  order  to  gain  a  better  understanding  of  their  functionality.  The 
capabilities  and  functions  of  each  of  the  identified  existing  systems  were  researched  and 
defined.  Then  the  functions  of  each  system  were  mapped  to  the  required  system 
functions,  which  can  be  seen  in  Figure  33. 
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Figure  33.  AoA  Mapping  Existing  Systems  against  Functions 


By  mapping  each  of  the  existing  system’s  functions  to  the  required  DAS 
functions,  the  team  was  able  to  compare  and  identify  the  functional  gaps  for  each  of  the 
existing  systems.  The  systems  that  had  the  most  functional  gaps  were  then  eliminated 
from  further  consideration  one  by  one  until  half  the  number  of  systems  that  were 
originally  analyzed  remained,  leaving  the  top  eight  systems  with  the  least  gaps.  The  top 
eight  systems  that  were  selected  for  further  consideration  were  ACSRMS,  CIM,  GDSC 
Remedy,  MRDB,  NSLC-3M,  S2E,  Engineering  and  Supportability  Decision  System 
(ESDS),  and  Maintenance  Figure  of  Merit  (MFOM). 
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b.  Conducting  Swing  Weights  and  QFD  HOQs  to  Compare 
Existing  Systems 

After  down  selecting  to  eight  existing  systems,  the  team  worked  with  the 
stakeholders  to  evaluate  and  prioritize  requirements  using  a  swing  weight  model. 
Swingwise  comparison  was  used  vice  pairwise  or  other  simple  weighting  systems 
because  the  swingwise  comparison  considers  not  only  importance  but  range  of  variance 
(Parnell  and  Trainor  2009).  One  requirement  may  be  the  most  important  to  a  stakeholder, 
but  the  range  of  solutions  to  meet  that  requirement  may  be  so  small  that  the  overall 
product  success  is  not  impacted.  A  list  of  top-level  requirements  was  developed  by 
meeting  with  stakeholders  and  then  swing  weight  methodology  was  used  to  create  the 
stakeholder  attribute  rankings.  Instead  of  ranking  the  requirements  against  each  other  in  a 
pairwise  comparison,  the  stakeholders  were  asked  to  evaluate  the  full  range  of  the 
specific  attribute  when  comparing.  The  stakeholders  were  asked  to  determine  the 
requirement  that  offers  the  best  improvement  from  known  ranges  and  to  assign  a  value  of 
100  to  it.  The  remaining  requirements  were  then  analyzed  to  determine  their  range  of  bad 
to  good  against  the  range  of  the  top  requirement.  For  example,  if  the  swing  from  worst 
case  to  best  case  on  a  specific  requirement  was  60%  as  good  as  the  swing  for  the  top 
requirement,  it  received  a  score  of  60.  This  formed  a  utility  function  based  on 
stakeholder’s  preferences.  Figure  34  shows  the  net  result  of  this  process. 
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Top  Level  Requirements 

Swing 

Weight 

Utility 

Swing  Weights 
normalized 

Rank 

External  Interface 

20 

0.021 

14 

Fleet  Maintenance  Support 
Data  and  Metrics 

75 

0.080 

5 

Logistics  Data 

50 

0.053 

8 

Training  Data 

50 

0.053 

8 

RMA  Analysis  Data 

50 

0.053 

8 

Reports 

75 

0.080 

5 

Human  System  Integration 

SO 

0.0S5 

3 

Reliability 

100 

0.107 

1 

Maintainability 

33 

0.035 

13 

Environment  Condition 

20 

0.021 

14 

Data  Collection 

50 

0.053 

8 

Accessible  by  authorized 
NMCI  Users 

70 

0.075 

7 

Data  Reporting 

50 

0.053 

8 

NMCI  Compliance 

SO 

0.006 

3 

Hardware  Requirements 

10 

0.011 

16 

Software  Requirements 

10 

0.011 

16 

Fleet  Access 

S5 

0.101 

2 

Figure  34.  Swing  Weight  Utility  Function  for  Top  Level  Requirements 


A  QFD  HOQ  model  was  then  used  to  prioritize  technical  characteristics 
against  top-level  requirements.  QFD  HOQ  was  chosen  based  on  the  focus  of  the 
stakeholder  requirements.  As  the  main  task  for  this  project  was  to  design  a  real  system  for 
supporting  the  USN  fleet,  there  needed  to  be  a  logical  path  from  needs  to  a  solution. 
“HOQ  constitutes  a  team  approach  to  help  ensure  that  the  ‘voice  of  the  customer’  is 
reflected  in  the  ultimate  design”  (Blanchard  and  Fabrycky  2011,  82).  The  normalized 
weights  obtained  from  the  top-level  requirements  swing  weight  matrix,  shown  in  Figure 
34,  were  used  as  inputs  into  the  HOQ  shown  in  Figure  35.  This  method  for  analysis 
provides  traceability  from  stakeholder  requirement  evaluations  to  technical  characteristics 
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to  system  functions  to  alternative  solutions,  allowing  the  team  to  select  an  alternative 
solution  based  on  stakeholder  preferences  (Blanchard  and  Fabry cky  2011). 

On  the  HOQ,  the  top-level  requirements  were  the  “What’s”  and  the  key 
technical  characteristics  were  the  “How’s”  of  the  DAS.  The  technical  characteristics 
include  aspects  that  affect  the  design  and  operation  that  can  be  measured  with  respect  to 
the  current  requirements.  The  HOQ  was  also  provided  to  the  stakeholders  to  obtain  an 
indication  of  the  stakeholders’  judgment  of  the  impact  of  the  technical  characteristics  on 
the  requirements.  The  following  non-linear  scale  was  used  by  stakeholders  to  indicate  the 
weight  of  impact  of  technical  characteristics  on  requirements: 


Not  related  or  low  importance  left  blank 

Necessary  1 

Important  3 

Critical  9 
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Technical  Characteristics  (Hows) 

Top  Level  Requirements  (Whats) 

Weight 

Accuracy 

Accessibility 

j5 

ra 

-i—' 

Cl 

in 

TJ 

< 

Completeness 

Flexibility 

Human  Factors 

Maintainability 

Reliability 

Timeliness 

Time  of  Report  Generation 

External  Interface 

0.021 

9 

9 

9 

3 

Fleet  Maintenance  Support  Data  and  Metrics 

0.080 

9 

9 

3 

3 

9 

Logistics  Data 

0.053 

9 

9 

3 

3 

9 

Training  Data 

0.053 

9 

9 

3 

3 

9 

RMA  Analysis  Data 

0.053 

9 

9 

3 

3 

9 

Reports 

0.0-80 

9 

9 

3 

3 

9 

Human  System  Integration 

0.006 

3 

3 

9 

Reliability 

0.107 

3 

1 

9 

9 

3 

Maintainability 

0.035 

3 

1 

9 

9 

3 

Environment  Condition 

0.021 

1 

1 

9 

Data  Collection 

0.053 

9 

3 

3 

9 

3 

1 

1 

9 

9 

Accessible  by  authorized  NMCI  Users 

0.075 

9 

1 

1 

Data  Reporting 

0.053 

9 

3 

3 

9 

3 

1 

1 

9 

9 

NMCI  Compliance 

0.096 

9 

1 

1 

Hardware  Requirements 

0.011 

3 

9 

3 

1 

1 

1 

3 

9 

Software  Requirements 

0.011 

3 

9 

3 

9 

1 

1 

3 

3 

Fleet  Access 

0.101 

3 

9 

3 

9 

3 

9 

9 

9 

Total 

1.00 

Weighted  Performance 

4.142 

3.44-8 

1.183 

4.142 

1.197 

3.033 

1.708 

2.316 

2.958 

5.303 

Percent  Performance 

0.141 

0.117 

0.040 

0.141 

0.041 

0.103 

0.058 

0.079 

0.101 

0.180 

II.I.I  ■  I 


Figure  35.  HOQ1  Requirements  to  Technical  Characteristics 


From  Figure  35,  using  the  normalized  weights  produced  by  the  HOQ,  it  can 
be  concluded  that  Time  of  Report  Generation,  Accuracy,  and  Completeness  were  the  most 
critical  technical  characteristics  for  the  DAS.  The  HOQ  results  suggested  that  the  most 
critical  characteristics  were  related  to  the  overall  goal  of  providing  a  fast,  easy  to  use, 
useful,  and  effective  system  to  the  user.  Furthermore,  it  is  important  to  note  that  the  HOQ 
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results  aligned  with  the  feedback  obtained  from  the  stakeholders’  needs  analysis,  further 
demonstrating  that  the  results  of  the  process  followed  by  the  team  accurately  reflects  the 
preferences  of  the  stakeholders. 

A  second  QFD  HOQ,  shown  in  Figure  36,  was  used  to  map  technical 
characteristics  to  functions.  The  normalized  weights  obtained  from  the  previous  QFD  HOQ 
were  used  as  inputs  into  the  second  HOQ,  continuing  with  the  traceability  from 
requirements  to  technical  characteristics  to  functions.  The  HOQ  was  also  given  to  the 
stakeholders  to  obtain  an  indication  of  the  stakeholders’  opinion  of  the  impact  of  the 
functions  on  the  technical  characteristics  and  the  same  non-linear  scale  was  used. 
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Functions  (Hows) 

technical  Characteristics  (Whats) 

Weight 

Provide  External  Interface 

Provide  User  1  nt  erf  ace 

Obtain  Data 

Obtain  Data  from  User  Inputs 

Obtain  Data  from  Fleet 

Obtain  Data  from  Fleet  Support  Infrastructure 

Process  Data 

Process  General  Information 

Process  Maintenance  Data 

Process  Logistics  Data 

Process  Training  Data 

Analyze  Data 

Analyze  Maintenance  Data 

Conduct  System  Performance  Trending  Analysis 

Compute  System  Ao/Ai  based  on  RMA  data 

Conduct  Cost  Analysis 

Report  Data 

Generate  System  Assessment  Report 

Generate  Logistics  Report 

Generate  System  Status  Report 

Generate  System  RMA  Report 

Display  Data 

Display  Fleet  Support  Information 

Display  Historical  Fleet  Data 

Display  Corrective  Maintenance  Information 

Display  Logistics  Information 

Display  RMA  Analysis  Data 

Print  Data 

Accuracy 

0.141 

3 

9 

9 

9 

9 

9 

9 

9 

3 

3 

9 

9 

9 

9 

3 

9 

9 

3 

9 

9 

9 

9 

9 

9 

3 

9 

1 

Accessibility 

0.117 

9 

9 

3 

3 

3 

3 

Adaptability 

0.040 

9 

1 

9 

9 

9 

9 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

9 

Completeness 

0.141 

3 

9 

9 

9 

9 

9 

9 

9 

3 

3 

9 

9 

9 

9 

3 

9 

9 

3 

9 

9 

9 

9 

9 

9 

3 

9 

1 

Flexibility 

0.041 

9 

9 

9 

9 

9 

3 

3 

3 

3 

3 

1 

1 

1 

1 

1 

3 

3 

3 

3 

3 

9 

9 

9 

9 

9 

9 

9 

Human  Factors 

0.103 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

Maintainability 

0.058 

3 

3 

3 

3 

3 

3 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Reliability 

0.079 

3 

9 

3 

3 

3 

3 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Timeliness 

0.101 

1 

9 

9 

9 

9 

9 

3 

3 

3 

3 

3 

Time  of  Report  Generation 

0.180 

3 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

3 

3 

3 

3 

3 

3 

3 

Total 

1.00 

Weighted  Performance 

2.8 

6.3 

6.5 

6.5 

6.5 

6.5 

4.6 

4.6 

4.6 

2.9 

2.9 

4.2 

4.2 

4.2 

4.2 

2.5 

5.5 

5.5 

3.8 

5.5 

5.5 

4.6 

4.6 

4.6 

4.6 

2.9 

4.6 

2.6 

Percent  Performance 

0.022 

0.049 

0.051 

0.051 

0.051 

0.051 

0.036 

0.036 

0.036 

0.023 

0.023 

0.033 

0.033 

0.033 

0.033 

0.020 

0.043 

0.043 

0.029 

0.043 

0.043 

0.036 

0.036 

0.036 

0.036 

0.023 

0.036 

0.020 

Figure  36.  HOQ2  Technical  Characteristics  to  Function 
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From  Figure  36,  using  the  normalized  weights  produced  by  the  second  HOQ,  the  key 
functions  identified  include:  1)  provide  user  interface,  2)  obtain  data,  3)  obtain  data  from 
user  inputs,  4)  obtain  data  from  fleet,  and  5)  obtain  data  from  fleet  support  infrastructure. 

Finally,  the  third  QFD  HOQ,  as  shown  in  Figure  37,  mapped  functions  to 
existing  systems.  As  was  the  case  with  the  previous  HOQs,  the  normalized  weights  from 
the  second  HOQ  were  entered  as  inputs  for  this  HOQ.  Furthermore,  as  with  the  previous 
HOQs,  the  HOQ  was  provided  to  the  stakeholders  to  obtain  an  indication  of  the 
stakeholders’  opinion  of  the  impact  of  the  existing  systems  on  the  functions  and  the  same 
non-linear  scale  was  used.  The  team  used  the  third  HOQ  in  order  to  rank  the  previously 
identified  top  eight  existing  systems  and  come  up  with  the  performance  weight  for  each 
system. 
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Figure  37.  HOQ3  Functions  to  Existing  Systems 
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From  Figure  37,  by  comparing  the  performance  weights  produced  by  the  HOQ,  the  top 
four  existing  systems  were  identified,  which  were  ESDS,  ACSRMS,  MFOM,  and 
MRDB. 


c.  Gap  Analysis 

In  order  to  identify  the  best  Alternative  6,  an  existing  system  that  could  be 
modified  for  DAS,  from  the  top  four  systems  identified  by  using  Swing  Weights  and 
QFD  HOQs,  the  team  used  the  third  QFD  HOQ,  which  mapped  existing  systems  to 
functions,  to  conduct  a  functional  gap  analysis.  All  of  the  functions  that  were  missing  by 
each  of  the  top  four  existing  systems  were  listed.  The  results  can  be  seen  in  Table  7. 
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Existing  Systems 

Gaps  (Functions) 

Engineering  and  Supportability 
Decision  System  (ESDS) 

Obtain  Data  from  Fleet 

Process  General  Information 

Process  Training  Data 

Display  Fleet  Support  Information 

Display  Corrective  Maintenance  Information 

Aegis  Combat  System  Reliability 
Maintainability  and 

Supportability  Database 
(ACSRMS) 

Obtain  Data  from  Fleet 

Process  General  Information 

Process  Training  Data 

Generate  System  Assessment  Report 

Display  Fleet  Support  Information 

Display  Corrective  Maintenance  Information 

Maintenance  Figure  of  Merit 
(MFOM) 

Obtain  Data  from  Fleet 

Process  General  Information 

Process  Training  Data 

Conduct  Cost  Analysis 

Generate  System  Assessment  Report 

Display  Fleet  Support  Information 

Display  Corrective  Maintenance  Information 
Display  Logistics  Information 

Material  Readiness  Database 
(MRDB) 

Obtain  Data  from  Fleet 

Process  General  Information 

Process  Training  Data 

Generate  System  Assessment  Report 

Display  Fleet  Support  Information 

Display  Corrective  Maintenance  Information 

Table  7.  Gap  Analysis  Chart 


The  number  of  gaps  for  each  system  was  then  used  as  a  metric  to  evaluate 
the  remaining  systems.  Table  7  shows  that  ESDS  has  only  five  functional  gaps  while 
ACSRMS  and  MRDB  have  six  and  MFOM  has  eight.  Furthermore,  it  can  be  noted  that 
all  of  ESDS’  functional  gaps  are  also  functional  gaps  for  the  other  three  systems.  In  other 
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words,  the  other  three  systems  had  at  least  the  same  functional  gaps  as  ESDS.  As  a  result, 
the  best  solution  based  on  the  least  amount  of  functional  gaps  was  ESDS. 

After  identifying  ESDS  to  be  the  existing  system  with  the  least  functional 
gaps,  the  team  continued  the  AoA  process  by  examining  system  documentation  for  each 
of  the  four  systems.  The  following  findings  resulted  from  that  process:  1)  ACSRMS  was 
no  longer  supported  by  the  contractor,  thus  it  was  eliminated  as  a  potential  solution,  2) 
the  results  of  MFOM  and  MRDB  analyses  showed  that  ESDS  already  aggregates  data 
from  both  systems  and  3)  MFOM  and  MRDB  have  limited  data  aggregation  capability, 
significantly  increasing  the  amount  of  effort  that  would  be  required  to  make 
modifications.  Since  ESDS  already  aggregates  data  from  MFOM  and  MRDB,  and  both 
systems  have  limited  data  aggregation  capability,  the  team  determined  that  modifying 
ESDS  was  the  most  suitable  existing  system  option  for  Alternative  6  that  would  meet  the 
needs  of  the  stakeholders  and  solve  the  problem.  To  distinguish  between  the  existing 
ESDS  and  the  modified  ESDS,  the  team  has  acquired  the  term  “ESDS  Plus”  (ESDS+) 
and  has  utilized  it  for  the  rest  of  this  report. 

H.  COST  ANALYSIS 

In  today’s  budget  constrained  environment,  all  government  spending  is  subject  to 
scrutiny.  Fleet  and  shore  based  activities  are  under  extreme  pressure  to  minimize  costs, 
but  weapon  system  availability  requirements  are  higher  than  ever.  While  many  efforts  to 
increase  fleet  readiness  have  been  extremely  costly,  Distance  Support  can  reduce  costs 
for  shore-based  activities  and  the  ships  they  support.  Although  initial  development  costs 
can  be  high,  by  reducing  travel  requirements,  supporting  system  operability,  and  lowering 
MTTR,  Distance  Support  is  an  extremely  valuable  tool  that  can  provide  a  ROI  in  a  very 
short  period  of  time. 

1.  Costs  Overview 

The  costs  for  a  Distance  Support  system  can  be  broken  down  into  four  categories: 

1)  development  costs,  2)  life  cycle  costs,  3)  disposal  costs  and  4)  savings.  Distinguishing 

between  these  costs  will  help  to  estimate  initial  costs,  and  extrapolate  over  time  to 

determine  life  cycle  costs  at  specific  future  dates.  Disposal  costs  will  be  incurred  when 
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the  system  is  replaced  and  disposed  of  in  the  future,  and  with  these  costs  accounted  for, 
overall  total  life  cycle  cost  can  be  determined. 

a.  Development  Cost 

Development  costs  include  all  costs  associated  with  the  development  of  a 
new  system.  Major  costs  associated  with  development  costs  are  1)  stakeholders’  needs 
analysis,  2)  requirements  analysis,  3)  programming  costs,  and  4)  early  beta  testing 
debugging  efforts.  These  costs  are  non-recurring,  as  they  take  place  only  during  the 
development  of  the  system.  In  the  case  of  systems  with  hardware,  this  may  include 
installation  and  the  testing  of  the  hardware  systems  when  it  is  installed  or  fielded. 

For  the  purpose  of  this  project,  the  team  assumed  that  the  DAS  will  utilize 
basic  processing  requirements,  and  therefore  will  not  require  extensive  hardware 
development  or  installation.  This  will  both  reduce  the  installation  costs,  as  well  as 
disposal  costs. 


b.  Life  cycle  Cost 

Life  cycle  costs  include  all  costs  required  to  support  the  fielded  active 
system.  These  costs  include  1)  technical  support,  2)  training,  3)  monitoring  and 
troubleshooting  costs,  4)  debugging  efforts,  5)  information  assurance  updates,  and  6) 
incremental  updates  to  keep  the  system  running  effectively. 

For  DAS,  the  majority  of  life  cycle  costs  will  be  incurred  through 
debugging  and  troubleshooting,  information  assurance,  and  incremental  updates.  An 
automated  DAS  will  require  minimal  oversight,  so  full  time  support  employees  are  not 
likely  to  be  necessary  to  the  support  of  the  system.  Periodic  maintenance  contracts  to  a 
contractor  may  suffice,  which  will  help  maintain  low  life  cycle  costs. 

Current  NSWC  PHD  funding  given  to  ESDS  for  life  cycle  support  is 
approximately  $245,000  per  year.  In  addition  to  traditional  life  cycle  support  efforts,  this 
includes  contractor  support  to  help  train  NSWC  PHD  engineers  to  use  the  system.  This 
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allocation  of  monies  also  funds  full  time  contractors  to  support  data  acquisition  support 
for  NSWC  PHD  command-sponsored  studies  and  briefings  such  as  SEAR  briefings  for 
combat  system  elements. 

c.  Disposal  Costs 

Disposal  costs  include  all  costs  associated  with  disposing  the  final  system 
at  the  end  of  its  life,  including  1)  system  hardware  removal  costs,  2)  destruction  or 
demilitarization  costs,  and  3)  physical  disposal  costs.  In  some  cases,  parts  of  the  systems 
can  be  demilitarized  and  reutilized  as  a  cost  avoidance  technique. 

For  a  software  focused  DAS,  with  minimal  hardware  installation,  disposal 
costs  will  be  negligible  in  comparison  to  development  costs,  life  cycle  costs,  and  savings, 
and  therefore  can  be  ignored  for  this  project. 

d.  Savings 

Distance  Support  has  the  ability  to  save  costs  in  several  important  areas. 
Effective  Distance  Support  applications  can  reduce  repair  time,  reduce  the  number  of 
onsite  CASREP  SME  technical  assists,  and  most  importantly  stop  system  issues  from 
preventing  a  ship  to  complete  a  mission. 

For  the  stakeholders  at  NSWC  PHD,  DAS  could  result  in  major  travel  cost 
reductions.  Navy  Sailors  primarily  submit  CASREPs  to  notify  shore  based  activities  of 
major  system  failures.  NSWC  PHD,  as  the  ISEA  for  many  of  these  Navy  systems,  is 
called  upon  to  fix  CASREPs.  These  engineering  efforts  supported  by  shore-based 
activities  such  as  NSWC  PHD  often  require  an  on-site  technical  subject  matter  to  visit  the 
ship  in  need.  These  trips  are  costly  due  to  travel  expenses  and  labor,  so  an  overall 
reduction  in  travel  can  have  major  cost  savings  for  shore  based  activities. 

(1)  Time  Savings  -  The  effective  utilization  of  Distance 
Support  will  save  both  fleet  end  users  and  shore  based  support  activities  valuable  time 
when  working  to  correct  system  issues.  This  means  Sailors  have  to  spend  less  time 
troubleshooting  their  systems,  and  they  can  spend  more  time  on  other  tasks  and  auxiliary 
functions. 
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(2)  Value  of  Reduced  Downtime  -  The  most  valuable  aspect  of 
effective  Distance  Support  is  the  improvements  to  Ao  and  reduction  in  system  downtime. 
Determining  the  value  of  reduced  system  downtime  can  be  a  difficult  and  subjective 
determination. 

If  a  system  failure  is  critical,  the  impacts  could  greatly  increase 
costs.  There  is  usually  not  a  second  ship  that  can  immediately  fill  the  mission 
requirements  if  a  deployed  ship  has  a  major  system  failure.  This  means  in  time  of 
national  crisis  or  international  tensions  and  a  USN  ship  is  required  to  be  deployed  it  is 
imperative  that  ship  remains  at  maximum  operational  readiness  levels. 

2.  Development  Cost  Analysis  through  Constructive  Systems 
Engineering  Cost  Model  (COSYSMO) 

Through  the  AoA,  the  team  determined  two  options  to  meet  the  DAS 
requirements:  1)  modify  ESDS  and  2)  build  a  new  Distance  Support  system.  The  team 
determined  the  development  costs  associated  with  both  options  by  using  the  COSYSMO 
Version  2.0.  COSYSMO  2.0  is  a  systems  engineering  cost  estimation  tool  that  was  a 
development  effort  between  NPS  and  University  of  Sothem  California  (USC),  built  on  a 
framework  developed  by  COSYSMO  model  developer  Dr.  Ricardo  Valerdi  of 
Massachusetts  Institute  of  Technology  (MIT).  COSYSMO  can  be  effectively  used  by 
systems  engineers  to  estimate  cost  for  developing  software  systems. 

COSYSMO  can  be  found  at  http://cosysmo.mit.edu/wp-content/uploads/ 
2010/1  l/academicCOSYSMO_2.0.xls  and  instructions  on  it  use  can  be  found  at  several 
sites,  including:  http://powershow.com/viewl/ld7deb-NDFiY/Towards_COSYSMO_20_ 
Future_Directions_and_Priorities_CSSE_Annual_Research_Review_Los_Angeles_CA_ 
powerpoint_ppt_presentation.  COSYSMO  is  a  model  used  to  compute  an  estimated 
number  of  person-months  of  a  project  will  require.  COSYSMO  has  been  calibrated  with 
the  data  sets  from  multiple  DoD  organizations  and  companies  to  enhance  the  accuracy  of 
the  model. 

The  application  of  COSYSMO  has  been  used  to  determine  which  of  the  two 
options  would  require  less  engineering  effort  to  develop.  The  specific  version  of  the  tool 
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that  the  team  used  was  COSYSMO  2.0  because  it  allows  users  to  account  for  redesign 
efforts.  This  was  necessary  to  compare  the  new  system  to  the  estimated  costs  of 
redesigning  ESDS  to  meet  the  requirements. 

COSYSMO  takes  in  a  specific  set  of  pre-defined  user-inputs.  The  COSYSMO  2.0 
Software  Documentation,  titled  Systems  Engineering  Cost  Estimation  with  COSYSMO, 
which  was  written  by  Ricardo  Valerdi  from  the  Massachusetts  Institute  of  Technology  in 
2008,  provides  extremely  specific  definitions  for  each  degree  of  complexity  for  factors 
that  will  drive  software  size,  and  software  cost.  By  making  the  definitions  of  each  degree 
of  complexity,  there  is  less  ambiguity  when  predicting  input  parameters.  As  a  result, 
COSYSMO  more  accurately  estimates  costs  across  a  variety  of  platforms  and  a  wide 
range  of  users.  The  following  section  covering  COSYSMO  inputs  describes  the  pre¬ 
defined  inputs  that  a  COSYSMO  user  needs  to  determine  for  their  system  and  select 
when  using  the  cost  estimation  tool. 

a.  COSYSMO  Inputs: 

Size  Drivers:  The  numbers  of  requirements,  algorithms,  interfaces,  and 
operational  scenarios  to  be  entered  into  COSYSMO  as  inputs  are  broken  down  into 
several  categories.  The  size  drivers  are  differentiated  and  entered  into  COSYSMO  based 
on  degree  of  complexity  (easy,  nominal,  and  difficult). 

(1)  COSYSMO  Size  Drivers-Size  drivers  are  factors  that 
influence  the  final  developed  system’s  software  size  and  complexity.  Each  input  directly 
increases  the  number  of  source  lines  of  code  (SLOC)  of  the  final  system.  Size  driver 
inputs  for  COSYSMO  are  as  follows  for  a  New  System: 

•  Number  of  Requirements 

•  Number  of  Interfaces 

•  Number  of  System  Specific  Algorithms 

•  Number  of  Operational  Scenarios. 
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For  a  redesigned  system,  the  inputs  are  the  same,  but  each  driver  is 
broken  down  further  into  these  categories:  1)  reused,  2)  modified,  3)  deleted,  4)  adopted 
and  5)  managed.  These  inputs  are  then  fed  through  a  ruse  algorithm  to  convert  these 
inputs  to  an  equivalent  number  of  new  input  parameters. 

(2)  COSYSMO  Cost  Drivers-cost  drivers  are  input  parameters 
that  impact  the  overall  development  cost  of  the  system  based  on  factors  that  do  not 
necessarily  impact  the  actual  software  size.  Cost  drivers  are  broken  down  into  two 
different  categories:  application  factors  and  team  factors.  Application  factors  impact  the 
complexity  of  the  system  due  to  the  installed  platforms,  documentation  requirements,  and 
other  general  factors  that  complicate  the  operational  scenario  of  the  final  system.  Team 
factors  are  the  various  factors  that  impact  the  development  team’s  ability  to  develop  and 
build  the  system. 

COSYSMO  Cost  Drivers  are  all  also  broken  down  by  complexity: 
1)  very  low,  2)  low,  3)  nominal,  4)  high,  5)  very  high,  and  6)  extra  high. 

Application  Factors: 

•  Requirements  Understanding 

•  Architecture  Understanding 

•  Level  of  Service  Requirements 

•  Migration  Complexity 

•  Technology  Maturity 

•  Documentation  Match  to  Life  Cycle  Needs 

•  Number  and  Diversity  of  Installations/Platforms 

•  Number  of  Recursive  Levels  of  the  Design 

Team  Factors: 

•  Stakeholder  team  cohesion 

•  Personnel/team  capability 
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•  Personnel  experience/  continuity 

•  Process  capability 

•  Multisite  coordination 

•  Tool  Support 

Figures  38  and  39  show  the  input  variables  that  were  used  to  run 
the  COSYSMO  analysis.  Figure  38  depicts  the  inputs  for  ESDS+  while  Figure  39  depicts 
the  inputs  used  for  a  New  System. 
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Figure  38.  Expert  COSYSMO  Inputs  -  ESDS+ 
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Nominal 

Nominal 

d 

High 

T 

Calculate 


Figure  39.  Expert  COSYSMO  Inputs  -  New  System 
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b.  COS  YSM O  A  nalysis: 

To  determine  COSYSMO  input  values,  the  system  requirements  from  the 
requirements  analysis  was  used.  The  complexity  of  each  requirement  was  used  to 
determine  the  complexity  of  each,  to  determine  the  approximate  number  of  system- 
specific  algorithms  that  would  be  needed,  and  to  identify  the  number  of  system  interfaces 
and  the  complexity  of  each  of  those  interfaces.  Next,  each  function  was  mapped  to  the 
two  systems  to  be  compared  to  determine  which  of  the  functions  would  lead  to  a  new 
requirement  for  development  or  an  existing  requirement  already  completed  that  can  be 
modified  and  reutilized. 

For  the  new  system,  each  of  these  requirements  was  entered  into 
COSYSMO  as  new  requirements.  For  the  improved  ESDS  system  (ESDS+),  each 
function  had  to  be  determined  as  a  new,  reused,  modified,  adopted,  or  managed 
requirement.  All  of  these  values  and  their  rankings  were  then  entered  into  COSYSMO. 

In  2012,  NSWC  PHD  conducted  a  funding  profile  analysis  and  created  a 
report  titled  ESDS  Cost  Breakdown.  In  this  analysis,  NSWC  PHD  estimated  costs  of 
future  ESDS  overhauls  to  include  additional  functionality  desired  by  NSWC  PHD 
management.  This  report  was  used  to  compare  the  COSYSMO  outputs  to  verify  the  cost 
estimates. 


3.  Development  Cost  Estimates  from  COSYSMO 

The  outputs  from  the  COSYSMO  Analysis  are  as  shown  in  Table  8. 


Option 

Estimated  Effort 

(Person-Months) 

Estimated  Effort  Less 

Tech.  Management 

ESDS+ 

102 

85 

New  System 

258 

214 

Table  8.  COSYSMO  Analysis  Outputs 
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The  team’s  assessments  indicate  that  the  estimated  development  effort  to 
modify  ESDS  to  meet  the  new  requirements  will  cost  40%  of  the  total  development  cost 
required  to  build  a  new  system. 

COSYSMO  computed  approximately  17%  of  the  total  cost  of  the  project 
as  “Technical  Management  Costs.”  This  expense  was  eliminated  because  NSWC  PHD 
contractors  will  be  conducting  the  work,  with  government  oversight  covering  the 
majority  of  technical  management  efforts.  It  was  estimated  that  one  person  month  was 
160  hours  of  labor,  and  a  software  engineer  contractor’s  cost  ranged  between  $50. 00/hour 
to  $100. 00/hour.  Taking  these  factors  into  account,  the  resulting  estimates  are  shown  in 
Table  9. 


Option 

Software  Engineer 

Hourly  Cost 

($50/hour) 

Software  Engineer 

Hourly  Cost 

($100/hour) 

ESDS+ 

$680,000 

$1,360,000 

New  System 

$2,064,000 

$4,128,000 

Table  9.  COSYSMO  Analysis  Outputs 


In  the  study,  ESDS  Cost  Breakdown,  cost  estimates  to  upgrade  the  functionality  of 
ESDS  was  in  the  range  of  $818,000  per  major  overhaul.  Thus  the  team  felt  confident  that 
their  AoA  cost  analysis  results  were  realistic. 

4.  Cost  Analysis  -  Monte  Carlo  Simulation 

Expert  COSYSMO  also  has  the  ability  to  run  a  simple  Monte  Carlo  Simulation 
based  on  the  user  inputs.  The  Monte  Carlo  Simulation  allows  the  user  to  determine  how 
uncertainty  in  the  variables  affects  the  projected  outcome  based  on  hundreds  or  even 
thousands  of  simulation  runs.  For  this  analysis,  the  Monte  Carlo  Simulation  outputs  a 


104 


range  of  system  development  effort  costs.  Figure  40  shows  the  Monte  Carlo  Simulation 
outputs  for  ESDS+  while  Figure  41  shows  the  Monte  Carlo  Simulation  outputs  for  a  new 
system. 


Monte  Carlo  Risk  Analysis  (1000  runs} 

Systems  Effort  Distribution  Function 

#  Iterations 

236 


59 


1 49-67  1 67-55  1 55-1 03  1 103-121  1 121-139  1 139-157 
Effort  (Person-Months) 


Systems  Effort  Confidence  Levels 


10% 

|  74 

20% 

|  S3 

30% 

|  91 

40% 

|  97 

50% 

1 1 03 

00% 

j  109 

70% 

1 116 

so% 

j  124 

90% 

1 1 34 

1 1 00% 

j  1 57 

Your  output  file  is  httc://c5se.  UBC.edu/tools/data/COSYSUO  January  5  2013  00  25  41  237339.txt 

Figure  40.  Expert  COSYSMO  Output  Monte  Carlo  Simulation  -  ESDS+ 
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Monte  Carlo  Risk  Analysis  [1000  runs} 


Systems  Effort  Distribution  Function 

#  Iterations 

276  271 


123-169  1 169-214  1 214-260  1 260-305  1 305-351  |  351-396 
Effort  (Pers on-Months} 


Systems  Effort  Confidence  Levels 


10% 

1 177 

20% 

1 203 

30% 

1 225 

40% 

1 240 

50% 

1 256 

S0% 

1 269 

70% 

1 2S7 

50% 

|  306 

30% 

1 331 

1  1  00% 

1 396 

Ydut  output  file  is  httEi  /csse.usc.edu/tooisj'data/COSYSMO  January  E-  2013  00  27  23  4SSSE-2.txt 

Figure  41.  Expert  COSYSMO  Output  Monte  Carlo  Simulation  -  New  System 

As  seen  in  Figures  40  and  41,  the  range  of  effort  in  person-months  can  vary  substantially. 
As  a  result,  there  is  some  noticeable  uncertainty  in  the  actual  effort  required  to  build  the 
DAS  solution.  This  will  have  to  be  factored  in  when  drafting  the  contract  for  the  DAS. 

I.  RISK  ANALYSIS 

Risk  analysis  began  at  the  commencement  of  this  research  effort,  following  the 
Risk  Management  Guide  for  DoD  Acquisition  written  in  2006.  Risk  factors  were 
included  in  the  cost  estimates  previously  discussed  in  this  report  to  see  if  mitigating  risk 
factors  would  affect  system  development  costs.  The  risk  analysis  process  was  to:  1) 
identify  risks,  2)  analyze  the  risks  identified  to  determine  their  severity  and  probability  of 
occurrence  and  3)  determine  how  the  risks  could  be  mitigated  or  controlled.  Table  10 
shows  the  adapted  severity  table  to  assess  risks. 
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Level 

Schedule 

1 

Minimal  or  no  impact 

2 

Able  to  meet  key  dates 

Slip  <  1  week 

3 

Minor  schedule  slip.  Able  to  meet  key 
milestones  with  no  schedule  float 

Slip  <  2.5  weeks 

4 

Program  critical  path  affected 

Slip  <  1  month 

5 

Cannot  meet  key  program  milestones 

Slip  >  1  month 

Table  10.  Risk  Consequence  Classification  (After  Office  of  the  Under  Secretary  of 

Acquisition,  Technology  and  Logistics  2006) 


The  probability  of  occurrence  is  as  important  as  the  severity  and  it  is  categorized 
by  the  criteria  in  Table  11. 


Level 

Likelihood 

Probability  of  Occurrence 

1 

Not  Likely 

<10% 

2 

Low  likelihood 

<30% 

3 

Likely 

<50% 

4 

Highly  likely 

<90% 

5 

Near  Certain 

<100% 

Table  11.  Risk  Likelihood  Classification  (From  Office  of  the  Under  Secretary  of  Acquisition, 

Technology  and  Logistics  2006) 


Upon  judging  the  severity  and  probability  of  a  negative  event,  the  specific  risk 


identified  can  be  classified  by  utilizing  the  chart  in  Figure  42.  “Stop  light”  colors  of  red, 
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yellow  and  green  are  used  to  categorize  the  risk.  The  goal  for  this  effort  was  to  move  any 
identified  risks  from  the  red  and  yellow  regions  to  the  green  region  via  mitigation. 


1  2  3  4  5 

Consequence 


Figure  42. 


Risk  Assessment  Matrix  (From  DoD  2006) 


The  team  identified  and  tracked  programmatic  and  technical  risks  for  the  project. 
The  following  details  the  analysis  of  the  highest  risks  of  both  categories: 

1.  Technical  Risks: 

For  technical  risk,  there  is  already  a  precedent  that  has  been  set  by  the  existing 
database  and  the  tool  set  programmers  that  exist  at  NSWC  PHD.  This  existing 
information  and  the  knowledge  of  NSWC  PHD  personnel  can  be  leveraged  in  the 
development  of  the  DAS.  Although  the  other  products  may  not  provide  a  complete 
Distance  Support  process,  they  are  stable  and  do  perform  tasks  with  data  as  designed. 
Following  the  DoD  risk  management  guide,  these  risks  will  need  to  be  monitored  on 
regular  basis  and  newly  identified  risks  will  be  added.  Figure  43  shows  these  Technical 
Risks. 
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Risk 

# 

Description 

Likelihood 

Consequence 

Response 

100 

Data  cannot  be  formatted  to  a 
standard  form  for 
consolidation 

Low 

Likelihood 

Cannot  meet 
key  program 
milestones 

Mitigate  risk  by  using 
NSWC  PHD  ISEA 
Stakeholders  to 
ensure  data  format 
viable 

101 

Data  cannot  be  "pulled" 
correctly  to  a  standard  form 
for  consolidation 

Low 

Likelihood 

Cannot  meet 
key  program 
milestones 

Control  risk  by 
utilizing  NSWC  PHD 
database  experts' 
heuristics  to  reduce 
likelihood  of 
occurring' 

102 

Data  being  consolidated  is 
resident  in  non-classified  and 
classified  sources;  Getting 
data  from  unclassified  to 
secret  enclaves  is  arduous  and 
could  cause  classified  spillage 
if  not  performed  properly 

Low 

Likelihood 

Program 
critical  path 
affected 

Ensure  all 

programmers  are  up 
to  date  in  "low  to 
high"  training  and 
utilize  established 
protocol  for  transfer 
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HSIand  Reliability  Deficient  in 
Testing 

Low 

Likelihood 

Minor 

schedule  slip 

Mitigate/Control  by 
using  the  "build  a 
little,  test  a  little" 
technique,  not  waiting 
for  the  end  of  the 
project  to  get 
feedback 

Risk  Assignment 


I  J  3  I  S 


I  J  3  1  S 


i  J  3  4  S 


5  1  1  *  S 

rufnc^ 


Figure  43.  Technical  Risks 
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2.  Programmatic  Risks: 

A  data  aggregation  tool  is  only  as  good  as  the  data  being  entered.  With  this  in 
mind,  a  review  of  the  solutions  for  issues  will  be  necessary  by  SMEs  for  accuracy.  Also, 
a  review  is  necessary  for  ensuring  that  the  tool’s  methodology  is  sound,  safe,  and 
consistent  with  the  documentation  being  used  and  agrees  with  known  best  practices.  In 
some  cases,  efficiencies  in  reporting  will  be  necessary,  since  many  SMEs  are  obligated  to 
track  personal  highlights  (weekly  accomplishments  for  personnel  reasons)  and  complete 
trip  reports.  The  intent  is  to  improve  the  existing  reporting  without  adding  workload  to 
the  experts  who  need  to  be  spending  their  time  on  providing  active  support.  Figure  44 
shows  these  programmatic  risks. 
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Risk 

# 


200 


201 


202 


Description 

Likelihood 

Consequence 

Response 

Human-In- Loop  element  is  not 
available  to  ensure 
consolidated  data  makes  sense 
and  is  accurate 

Low 

Likelihood 

At  least  one 
requirement  not 
met 

Control  risk  by 
utilizing  NSWC  PHD 
branch  headsto 

ensure  SMEs  are 
available 

Informative  narrative  useful 
data  not  entered  in  fields 

Likely 

At  least  one 
requirement  not 
met 

Control  risk  by 
requiring  review  of 
department  chief 
systems  engineers 
of  the  SME  input  to 
ensure  a  quality 
product 

DS  data  from  at  least  one 

NSWC  PH  D  System  is  not 
available  for  consolidation 

Low 

Likelihood 

At  least  one 
requirement  not 
met 

Mitigate  risk  by 
utilizing  NSWC 

PHD  Department 
Systems  Engineers 
to  ensure  data  is 
available 

RiskAssignment 


1 

■ 

l" 

X 

I  2  J  4  5 

CwtHqHKt 


Figure  44.  Programmatic  Risks 
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3. 


Cost  Risks: 


The  cost  estimation  tool  utilized  was  the  Expert  Constructive  Systems 
Engineering  Cost  Model  (Expert  COSYSMO).  It  provided  the  team  with  the  ability  to 
estimate  the  overall  system  cost  risk  by  analyzing  the  cost  driver  input  parameters.  This 
estimate  was  done  by  using  an  input  comparison  table  with  calibrated  risk  analysis 
comparing  each  input  against  all  others  and  looking  for  potentially  high  risk  areas. 

Whenever  a  risk  area  is  identified,  Expert  COSYSMO  provides  a  risk  value  and 
attempts  to  provide  a  risk  mitigation  strategy.  Expert  COSYSMO  identified  several  high, 
medium  and  low  risk  areas  for  both  modifying  ESDS  and  building  a  new  Distance 
Support  tool. 

Once  all  risk  areas  were  identified  and  risk  values  estimated,  an  overall  risk  value 
was  calculated  by  summing  all  of  these  values.  The  final  overall  risk  value  will  be  in  the 
range  of  zero  to  702.  The  risks  associated  with  each  option  are  summarized  in  Table  12. 
The  input  and  output  parameters  that  went  into  Expert  COSYSMO  can  be  found  in 
Appendix  C-Risk  Analysis  Through  COSYSMO. 


Number  of 

Number  of 

Number  of 

Option 

Low  Risk 

Medium 

High  Risk 

Total  Risk: 

Areas 

Risk  Areas 

Areas 

ESDS+ 

8 

4 

1 

44.7 

New  System 

11 

4 

1 

45.7 

Table  12.  Risks  Associated  with  Each  Option 


The  outputs  of  Expert  COSYSMO  require  review  because  it  does  not  have  insight 
to  the  systems  it  compares.  The  team  found  that  Expert  COSYSMO  gave  a  medium  risk 
for  “ESDS+”  because  Migration  Complexity  was  rated  as  high.  This  assessment  was 
determined  to  be  inaccurate  because  there  will  be  no  actual  migration  of  existing  ESDS 
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infrastructure,  rather  the  existing  system  will  simply  be  built  upon  in  a  next  major  system 
revision.  Therefore,  the  team  removed  this  from  the  Medium  risk  areas  and  moved  it  to 
Low  risk. 

For  both  systems,  the  Documentation  input  is  very  high  due  to  rigorous  DoD 
standards  and  requirements,  and  the  Number  and  Diversity  of  Platforms  is  Extra  high  due 
to  the  wide  range  of  potential  users  the  database  will  be  accessed  by.  These  two  factors 
combined  may  cause  major  issues  for  system  programmers,  builders  and  integrators.  As  a 
result  this  is  a  major  risk  area  for  both  systems. 

Tables  13  and  14  summarize  the  medium  and  low  risks  for  each  system,  as  well  as 
the  risk  mitigation  suggestions  from  Expert  COSYSMO. 


Risk  Mitigation  Strategy  from 

Risk 

Level 

Input  1 

Input  2 

Constructive  Systems 
Engineering  Cost  Model 

(COSYSMO) 

Documentation 
=  Very  High 

Diversity  of 
Platforms  = 

Extra  High 

Not  applicable 

Service 

Diversity  of 

Understand  baseline  functionality 

Requirements 

Platforms  = 

better  and  how  it  changes  across 

c n 

2 

S 

#=3 

QJ 

=  High 

Extra  High 

installations/platforms 

Level  of 

Service 

Stakeholder 

Tpam 

Put  people  with  experience  working 

S 

Requirements 
=  High 

=  Very  Low 

together  to  meet  the  high  ‘illities 

Level  of 

Service 

Documentation 

Extensive  documentation  to  support 

Requirements 
=  High 

=  Very  High 

traceability  for  high  interoperability 

X 

C/2 

2 

£ 

Migration 

Diversity  of 

Limit  legacy  system  involvement, 

Complexity  = 

Platforms  = 

reduce  the  number  of  interfaces  by 

© 

- 

High 

Extra  High 

defining  a  common  interface 
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Risk 

Level 

Input  1 

Input  2 

Risk  Mitigation  Strategy  from 
Constructive  Systems 
Engineering  Cost  Model 
(COSYSMO) 

Technology 

Risk  = 

Nominal 

Diversity  of 
Platforms  = 

Extra  High 

Early  identification  of  potential 
installations,  upfront  effort 
including  prototyping  to  cover  each 
installation 

Migration 
Complexity  = 
High 

Stakeholder 

Team  Cohesion 
=  Very  Low 

Enable  legacy  system 
communication  among  team 

Migration 
Complexity  = 
High 

Documentation 
=  Very  High 

Find  old  documents  and  people  to 
translate  them,  seek  analogous 
documentation  and  learn  from  it, 
reverse-engineer  old  system 

Technology 
Risk  = 

Nominal 

Stakeholder 

Team  Cohesion 
=  Very  Low 

Rigorous  enforcement  of  gate 
criteria  early,  increased 
coordination  and  frequency  of 
communication 

Technology 

Risk  = 

Nominal 

Documentation 
=  Very  High 

Prototype,  modeling  and 
simulation,  trade  studies 

Documentation 
=  Very  High 

Multisite 
Coordination  = 
Nominal 

Not  applicable 

Documentation 
=  Very  High 

#  of  Recursive 
Levels  in  Design 
=  Nominal 

Not  applicable 

Table  13.  Risk  Associated  with  Improving  ESDS 
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Risk 

Level 

Input  1 

Input  2 

Risk  Mitigation  Strategy  from 
Constructive  Systems  Engineering 
Cost  Model  (COSYSMO) 

Documentation 
=  Very  High 

Stakeholder 

Team  Cohesion  = 
Very  Low 

Not  applicable 

c n 

2 

Level  of 

Service 
Requirements 
=  High 

Diversity  of 
Platforms  =  Extra 
High 

Understand  baseline  functionality 
better  and  how  it  changes  across 
installations/platforms 

s 

5 

§ 

Level  of 

Service 
Requirements 
=  High 

Stakeholder 

Team  Cohesion 
Very  Low 

Put  people  with  experience  working 
together  to  meet  the  high  ‘illities 

Level  of 

Service 
Requirements 
=  High 

Documentation  = 
Very  High 

Extensive  documentation  to  support 
traceability  for  high  interoperability 

Technology 

Risk  = 

Nominal 

Diversity  of 
Platforms  =  Extra 
High 

Early  identification  of  potential 
installations,  upfront  effort  including 
prototyping  to  cover  each  installation 

Migration 
Complexity  = 
Nominal 

Diversity  of 
Platforms  =  Extra 
High 

Limit  legacy  system  involvement, 
reduce  the  number  of  interfaces  by 
defining  a  common  interface 

Low  Risk 

Architecture 
Understanding 
=  Nominal 

Diversity  of 
Platforms  =  Extra 
High 

Prototyping,  much  testing 

Technology 

Risk  = 

Nominal 

Stakeholder 

Team  Cohesion  = 
Very  Low 

Rigorous  enforcement  of  gate  criteria 
early,  increased  coordination  and 
frequency  of  communication 

Architecture 
Understanding 
=  Nominal 

Stakeholder 

Team  Cohesion 
Very  Low 

Setup  system  level  IPT’s  with 
customers,  involve  customers  early, 
prioritize  requirements 
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Risk 

Level 

Input  1 

Input  2 

Risk  Mitigation  Strategy  from 
Constructive  Systems  Engineering 
Cost  Model  (COSYSMO) 

Technology 
Risk  = 

Nominal 

Documentation  = 
Very  High 

Prototype,  modeling  and  simulation, 
trade  studies 

Documentation 
=  Very  High 

Multisite 
Coordination  = 
Nominal 

To  Be  Determined  (TBD) 

Documentation 
=  Very  High 

#  of  Recursive 
Levels  in  the 
Design 

Nominal 

TBD 

Documentation 
=  Very  High 

Process 

Capability  = 
Nominal 

Subcontract,  hire  or  partner  with 
high  process  domain  expertise 

Documentation 
=  Very  High 

Personnel /Team 
Capability  = 
Nominal 

TBD 

Architecture 
Understanding 
=  Nominal 

Documentation  = 
Very  High 

Do  more  documentation 

Table  14.  Risk  Associated  with  Building  a  New  System 


J.  SUMMARY 

The  purpose  of  the  requirements  analysis  was  to  translate  stakeholder  needs  into  a 
set  of  system  operational  requirements  and  maintenance  and  support  concepts.  Functional 
analysis  was  then  conducted  to  identify  the  system  resources  that  would  be  required  for 
DAS  to  achieve  the  operational  concept  that  was  developed  from  the  requirements 
analysis.  Using  the  results  of  the  requirements  analysis  and  functional  analysis,  the  team 
conducted  an  AoA  to  find  the  best  alternative  that  would  achieve  DAS  capabilities  the 
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stakeholders  need.  To  do  this,  a  number  of  alternatives  were  identified.  The  team 
determined  that  the  most  effective  alternatives  were  to  either  build  a  brand  new  system, 
or  to  modify  and  improve  an  existing  system  to  meet  the  needs  of  the  stakeholders.  Due 
to  the  number  of  existing  Distance  Support  systems  that  currently  exist,  the  team  had  to 
reduce  the  number  of  possible  systems.  The  team  defined  a  number  of  evaluation 
measures  and  metrics  so  each  system’s  performance  could  be  assessed  based  on  their 
current  capabilities.  Stakeholders  were  asked  to  complete  a  swing  weight  matrix  to 
determine  their  preference  weight  for  each  requirement.  Then  three  QFD  HOQs  were 
used  to  reduce  the  number  of  possible  existing  systems  to  four.  A  gap  analysis  was 
performed  to  determine  that  the  existing  system  with  the  least  amount  of  functional  gaps 
was  ESDS.  Cost  Analysis  was  conducted  using  COSYSMO  to  compare  the  two 
alternatives,  either  1)  modify  ESDS  (ESDS+)  or  2)  build  a  new  system.  The  results 
showed  that  ESDS+  would  cost  60%  less  than  building  a  new  system.  Thus,  if  the  SE 
hourly  cost  was  estimated  to  be  $50  per  hour,  ESDS+  would  cost  $680,000  and  the  new 
system  would  cost  $2,064,000  to  develop.  From  Risk  Analysis,  Expert  COSYSMO 
showed  that  ESDS+  had  less  risk  issues.  Expert  COSYSMO  evaluated  the  total  risk 
exposure  points  of  ESDS+  as  44.7  and  the  new  system  as  45.7. 
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IV.  SYSTEM  ARCHITECTURE  DESIGN 


The  third  step  in  the  SE  process  was  to  develop  the  system  architecture  of  DAS. 
To  do  this,  first  the  team  defined  the  requirements  which  translated  from  the 
stakeholder’s  needs  then  traced  the  requirements  to  the  system  functions,  allocated  the 
functions  to  the  components  and  established  all  the  relationships  between  the  functions 
and  components.  The  team  utilized  Vitech’s  CORE®  software  suite  to  document  the 
functional  architecture  and  the  analysis  as  discussed  in  Chapter  111.  Then,  DoDAF 
products  were  created  to  describe  the  DAS  architecture  in  the  graphical  and  tabular 
presentation.  The  team  used  the  DAS  architecture  to  instantiate  the  ESDS+  architecture, 
which  would  be  based  on  augmenting  the  current  ESDS  architecture. 

A.  ARCHITECTURAL  DEVELOPMENT  APPROACH 

The  system  architecture  was  developed  using  a  top-down  functional 
decomposition  and  allocation  approach.  According  to  Buede, 

The  functional  architecture  of  a  system  contains  a  hierarchical  model  of 
the  functions  performed  by  the  system,  the  system’s  components,  and  the 
system  configuration  items;  the  flow  of  informational  and  physical  items 
from  outside  the  system  through  the  transformational  processes  of  the 
system’s  functions  and  on  to  the  waiting  external  systems  being  serviced 
by  the  system;  a  data  model  of  the  system’s  items;  and  a  tracing  of 
input/output  requirements  to  both  the  system’s  functions  and  items  (Buede 
2009,211). 

IDEFO  was  used  as  the  graphical  process  modeling  technique  to  represent  the 
functional  architecture  of  the  DAS.  IDEFO  modeling  was  chosen  because  IDEFO  has 
well-defined,  standardized  syntax  and  semantics  that  distinguish  between  the  inputs  to  be 
transformed  into  outputs  and  the  control  information  that  guides  the  transformation 
process.  In  addition,  the  IDEFO  is  capable  of  representing  the  physical  architecture, 
namely  the  mechanism  within  IDEFO  (Buede  2009).  Specific  IDEFO  modeling  details  can 
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be  found  in  the  2009  National  Institute  of  Standards  and  Technology,  Integration 
Definition  for  Function  Modeling  (IDEFO).  An  example  of  IDEFO  syntax  is  shown  in 
Figure  45. 

The  primary  elements  of  IDEFO  diagrams  captured  within  this  document  are 
summarized  as  follows: 

•  Function-a  transformation  of  inputs  to  outputs,  by  means  of  some 
mechanism,  and  subject  to  certain  controls,  that  is  identified  by  a  function 
name  and  modeled  by  a  box 

•  Box-a  rectangle  containing  a  verb  or  verb  phase  and  representing  a 
function  in  a  diagram 

•  Input-represents  what  is  transformed  or  consumed  by  the  function  to 
produce  the  function’s  output 

•  Control-represents  conditions  that  must  be  met  before  the  function  can 
produce  correct  output;  used  as  the  stimulus  for  the  response  (e.g.  tasking, 
orders,  requests) 

•  Output-represents  what  is  produced  by  the  function 

•  Mechanism-represents  the  mechanism  for  the  function  or  in  other  words, 
the  means  to  carry  out  the  function. 
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Figure  45.  IDEFO  Syntax  Example 

The  methodology  for  developing  the  architecture  followed  a  hierarchal  approach. 
DoDAF  products  were  used  extensively  throughout  the  development  of  the  DAS 
architecture.  DoDAF  is  widely  used  by  organizations  developing  system  solutions  for  the 
DoD.  From  the  Architecture  Framework  Version  2.0,  Volume  1:  Introduction,  Overview, 
and  Concepts,  Managers  Guide,  DoDAF  V2.0  is  defined  as  the  “overarching, 
comprehensive  framework  and  conceptual  model  enabling  the  development  of 
architectures  to  facilitate  the  ability  of  DoD  managers  at  all  levels  make  key  decisions 
more  effectively”  (DoD  2009,  2).  Since  this  project’s  SE  process  would  not  follow  the 
entire  V-shaped  pattern  of  the  2009  DoD  SE  Model,  not  every  DoDAF  product  was 
created  for  this  project.  The  DoDAF  products  created  were  limited  to  the  Operational  and 
System  Views  and  only  the  products  that  were  applicable  to  the  DAS  architecture  and 
within  the  scope  of  the  capstone  project.  All  other  DoDAF  products  were  deferred  to 
future  work.  As  illustrated  in  Figure  46,  all  of  the  Operational  Views  (OV),  including:  1) 
Operational  View  (OV-1),  2)  Operational  Node  Connectivity  View  (OV-2),  3) 
Operational  Activity  View  (OV-5),  and  4)  Operational  Event  Trace  Description  (OV-6c), 
were  developed  during  the  stakeholder  requirement  definition  phase.  The  System  Views 
(SV)  shown  in  Figure  46,  including:  1)  System  Interface  Description  (SV-1),  2)  System 
Resource  Flow  Description  (SV-2),  3)  System  Functionality  Description  (SV-4),  and  4) 
Operational  Activity  to  System  Function  Traceability  Matrix  (SV-5a),  were  generated  to 

facilitate  the  requirements  analysis  and  architecture  design. 
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Figure  46.  DoDAF  Products  Development  Mapped  to  SE  Process 


The  DoDAF  products  were  built  based  on  the  sequence  depicted  in  Figure  47.  The 
build  sequence  was  derived  from  “DoDAF  Architecture  Framework,  Example  Build 
Process”  by  Don  Muehlbach,  Ph.D.  Each  view  builds  on  previous  views  and  can  result  in 
the  refinement  of  prior  views  as  the  architecture  matures.  The  OV-l  illustrates  the  high 
level  operational  view  of  USN  surface  fleet  conducting  Distance  Support  in  which  the 
DAS  is  considered  a  subsystem  of  the  overall  Distance  Support  System  of  Systems  (SoS). 
The  OV-5  depicts  and  decomposes  the  DAS  operational  activities  necessary  to  support 
that  mission.  The  OV-2  shows  the  connections  and  information  flows  among  various 
entities  (nodes)  needed  to  execute  those  activities.  The  OV-6c  reveals  the  time  sequence 
of  the  decomposed  activities.  The  SV-5a  maps  the  decomposed  operational  activities  to 
system  functions  (and,  by  extension,  to  systems).  The  SV-4  shows  the  connections  and 
information  flows  among  the  system  functions.  The  SV-l  describes  interfaces  required 
among  systems  to  perform  assigned  functions.  The  SV-2  specifies  the  system  resource 
flows  between  the  systems. 
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Figure  47. 


DoDAF  Products  Build  Sequence 


Table  15  provides  the  product  name  and  a  brief  definition  of  all  the  DoDAF  views  that 
were  developed  and  documented  as  the  architecture  artifacts  for  this  project. 
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Department  of 
Defense 
Architecture 
Framework 
(DoDAF) 
Product 

DoDAF  Product 
Name 

General  Description 

OV-1 

High  Level 
Operational 

Concept  Graphic 

High  level  graphical/textual  description  of 
operational  concept 

OV-2 

Operational  Node 

Connectivity 

Description 

Operational  nodes,  connectivity,  and 
information  exchange  need  lines  between 
nodes 

OV-5 

Operational 

Activity  Model 

Capabilities,  operational  activities, 
relationships  among  activities,  inputs,  and 
outputs,  overlays  can  show  cost,  performing 
nodes,  or  other  pertinent  information 

OV-6c 

Operational  Event 
Trace  Description 

One  of  the  three  products  used  to  describe 
operational  activity  -  identifies  business 
rules  that  constrain  operation 

SV-1 

Systems  Interface 
Description 

Identification  of  system  nodes,  systems,  and 
system  items  and  their  connections,  within 
and  between  nodes 

SV-2 

Systems 

Communications 

Description 

System  nodes,  systems,  and  system  items, 
and  their  related  communication  lay-down 

SV-4 

Systems 

Functionality 

Description 

Functions  performed  by  systems  and  the 
system  data  flows  among  system  functions 

SV-5a 

Operational 

Activity  to  Systems 
Function 

Traceability  Matrix 

Mapping  of  systems  back  to  capabilities  or 
of  system  functions  back  to  operational 
activities 

Table  15.  DoDAF  Products  Description 
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B.  OPERATIONAL  ARCHITECTURE 

1.  Operational  View  (OV-1) 

The  DAS  will  be  used  as  a  Distance  Support  tool  in  a  collaborative  secured 
environment  where  the  data  will  be  accessed  and  shared  by  multiple  entities  including 
ships  at  sea  and  shore  based  support  infrastructure.  Figure  48  illustrates  the  high  level 
concept  of  operation  of  the  DAS  hosted  by  NSWC  PHD  where  ships  communicate  with 
shore  based  infrastructure  via  satellite  communication  (SATCOM)  in  real  time  or  near 
real  time  as  parts  of  Distance  Support  with  respect  to  six  different  functions  of  Distance 
Support  as  indicated  at  the  bottom  of  the  diagram. 
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Figure  48.  Distance  Support  Operational  View  (OV-1) 
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2.  Operational  Nodes  Connectivity  (OV-2) 

The  Operational  Nodes  Connectivity  as  shown  in  Figure  49  illustrates  the  data 
required  for  aggregation  in  support  of  Distance  Support  are  exchanged  between  the  DAS 
located  at  NSWC  PHD  to  the  external  nodes  through  a  series  of  existing  unclassified  and 
classified  networks,  a  level  of  interconnectivity  currently  employed  by  the  Navy  today. 
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Figure  49.  Operational  Nodes  Connectivity  (OV-2) 
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3. 


External  Interface 


The  external  interface  between  the  DAS  and  other  systems  and/or  databases, 
where  the  maintenance  and  logistics  data  is  generated  by  the  ship,  will  be  collected  by 
DAS  through  multiple  data  sources  residing  in  different  organizations.  The  new  data 
exchange  is  illustrated  in  dotted  arrows  in  Figure  50  while  the  solid  arrows  indicated  the 
current  process  that  is  executed  in  the  Navy  support  infrastructure  today. 


Figure  50.  DAS  External  Interface  Diagram 
4.  Operational  Activities  (OV-5) 

The  next  step  in  the  architectural  development  phase  was  the  creation  of  the 
Operational  Activity  Model  (OV-5)  shown  in  Figures  51  and  52.  Due  to  the  size  of 
Figure  51,  Figure  52  was  provided  to  show  an  enlarged  figure  focused  on  the  Analyze 
Data,  Disseminate  Self  Help  Corrective  Maintenance  Data,  and  Disseminate  RMA 
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Trends  Data  blocks.  This  approach  decomposed  all  of  the  functions  into  their  component 
operations.  The  OV-5  system  was  modeled  using  the  IDEFO  format  to  better  illustrate  the 
flow  of  key  elements  necessary  for  the  system  to  accomplish  its  mission.  The  main 
activities  are:  1)  Establish  Network  Connection,  2)  Collect  Data,  3)  Process  Data,  4) 
Analyze  Data,  5)  Disseminate  Self  Help  Corrective  Maintenance  Data  and  6) 
Disseminate  RMA  Trends  Data.  Each  activity  consists  of  nodes  that  have  input,  output, 
control,  and  mechanism  flows  going  into  and  out  of  each  node. 
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Figure  51.  Operational  Activities  (OV-5) 
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Figure  52.  Enlarged  Operational  Activities  (OV-5) 
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The  first  node  is  to  “Establish  Network  Connection”  (A.  1.0).  This  allows  the  DAS 
to  connect  and  aggregate  data  from  other  fleet  support  infrastructure  systems  and/or 
databases  by  an  Internet  connection  provided  by  network  providers  such  as  NMCI  or 
Navy  Information  Technology  for  the  21st  Century  (IT-21).  After  the  network  connection 
is  established,  the  data  (fleet  data,  fleet  support  infrastructure  data,  and  user  input  data) 
will  be  collected  via  the  “Collect  Data”  node  (A.2.0)  either  automatically  (scheduled)  or 
manually  (from  the  user  interface).  The  “Collect  Data”  node  will  filter  the  data  into 
different  categories  such  as  1)  fleet  training  data,  2)  fleet  RMA  data,  3)  fleet  maintenance 
data,  and  4)  fleet  logistics  data.  The  collected  data  is  then  sent  to  the  “Process  Data” 
(A.3.0)  node  for  refinement.  The  fourth  node  is  “Analyze  Data”  (A.4.0).  At  this  node,  all 
the  data  will  be  analyzed  to  generate  multiple  end  products  such  as  1)  System 
Performance  Metrics,  2)  Corrective  Maintenance  Solution,  3)  Predictive  Trends  Analysis, 
and  4)  Life  Cycle  Cost  Metrics  that  will  be  sent  to  the  “Disseminate  Self  Help  Corrective 
Maintenance  Data”  (A.5.0)  node  and  the  “Disseminate  RMA  Trends  Data”  (A.6.0)  node 
to  make  the  data  available  for  the  stakeholder  access  either  in  the  form  of  a  report  or  a 
display  on  NSWC  PHD  web  pages. 

5.  Operational  Event  Trace  Description  (OV-6c) 

The  Operational  Event  Trace  Description  (OV-6c)  is  a  graphical  method  of 
describing  the  operational  activities  or  functions  that  are  performed  by  the  operational 
nodes  through  a  scenario  or  a  sequence  of  events  with  respect  to  time.  As  depicted  in 
Figure  53,  the  event  starts  with  the  “Establish  Network  Interface”  function,  which  is 
performed  automatically  by  all  the  nodes  through  a  series  of  Navy  enterprise  network 
connections  including  Navy  IT-21  and  NMCI.  After  the  connections  are  established,  the 
data  from  the  fleet  and  fleet  support  infrastructure  databases  are  sent  to  DAS  though  the 
external  functions  “Distribute  Ship  Data”  and  “Distribute  Fleet  Support  Data”  (the 
analysis  of  these  functions  are  not  within  scope  of  this  project).  The  next  events  are 
executed  by  the  functions  within  DAS  that  include:  1)  “Obtain  Data,”  2)  “Process  Data,” 
3)  “Analyze  Data,”  4)  “Report  Data,”  5)  “Display  Data,”  and  6)  “Print  and  Save  Data.” 
After  the  data  is  aggregated,  processed,  and  analyzed,  the  output  data  will  be  made 
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available  through  the  NSWC  PHD  Portal  for  the  ships  and  stakeholders  to  get  access  via 
the  “Access  Data”  function.  (The  “Access  Data”  function  is  not  covered  in  this  report 
due  to  the  limited  scope  of  this  project). 
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Figure  53.  Operational  Event  Trace  Description  (OV-6c) 

135 


C.  FUNCTIONAL  ARCHITECTURE 

1.  System  Functionality  Description  (SV-4) 

In  continuation  of  the  architectural  development  phase,  the  DAS  Functionality 
Description  (SV-4)  was  created  as  shown  in  Figure  54.  The  goal  of  the  SV-4  was  to 
specify  the  functional  decomposition  the  data  flows  among  the  functions  that  the  DAS 
must  perform.  As  defined  in  DoDAF  V2.0  Volume  2,  Architecture  Data  and  Model, 
Architect’s  Guide,  which  is  dated  28  May  2009,  the  purposes  of  the  SV-4  are  to  “develop 
a  clear  description  of  the  necessary  data  flows  that  are  input  (consumed)  by  and  output 
(produced)  by  each  resource,  to  ensure  that  the  functional  connectivity  is  complete,  and 
to  ensure  that  the  functional  decomposition  reaches  and  appropriate  level  of  detail”  (DoD 
2009,  206).  The  focus  of  the  SV-4  was  on  the  functions  themselves  and  the  order  in 
which  they  occur.  It  was  necessary  to  create  a  SV-4  since  a  system’s  functions  drive  its 
architecture,  or  in  other  words,  form  follows  function.  In  addition  to  providing  a  deeper 
understanding  of  what  functions  DAS  must  perform,  the  SV-4  fed  input  data  into  other 
architectural  products  such  as  the  functional  allocation  matrices  and  the  SV-5a.  DoDAF 
does  not  specify  what  functional  modeling  language  must  be  used  for  the  SV-4.  A  top 
down  approach  was  used  to  create  the  SV-4  diagram  which  each  “swim  lane”  lies  across 
horizontally  in  the  diagram  representing  the  high  level  system  functions.  The  SV-4  was 
created  within  the  context  of  the  OV-1,  OV-5,  and  system  boundary  diagram.  The 
functions  included  in  the  SV-4  needed  to  allow  the  DAS  to  meet  the  mission  described  by 
the  OV-1.  They  also  needed  to  be  aligned  to  some  operational  activity  within  the  OV-5. 
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Figure  54.  System  Functionality  Description  (SV-4) 
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2.  System  View  of  Operational  Activity  to  Systems  Function  Traceability 
Matrix  (SV-5a) 

The  Operational  Activity  to  System  Function  Traceability  Matrix  (SV-5a) 
identifies  activities  and  the  associated  system  functions  required  by  DAS  to  perform  the 
activities  successful.  The  SV-5a  relates  system  functions  from  the  SV-4  to  the  operational 
activities  from  the  OV-5.  The  SV-5a  illustrates  how  the  system  functions  support  DAS 
capability,  thus  identifying  the  transformation  of  an  operational  need  into  a  purposeful 
action  performed  by  DAS.  Figure  55  shows  the  mapping  between  an  operational  activity 
and  a  system  function  denoted  by  a  dot  to  assess  the  status  of  the  system  function. 


138 


Function 

X  XX/  / XxX / 

/if/  /  /  xx/xx 
/Jy  /  /  / X/Xy 

*f  Ay  /  /  AAA/y 
/fy  /  /  /fsW 

^x4/^4x4%y 

/  /  V/  <0  /  <o*/ 

F.O 

Provide  Data  Aggregation  Capability 

F.1.0 

Provide  External  Interface 

• 

F.1.1 

Execute  System  Interface 

• 

F.2.0 

Obtain  Data 

F.2.1 

Obtain  Data  from  User  Inputs 

• 

F.2.2 

Obtain  Data  from  Fleet 

• 

F.2.3 

Obtain  Data  from  Fleet  Support  Infrastructure 

• 

F.3.0 

Process  Data 

F.3.1 

Process  General  Information 

• 

F.3.2 

Process  Maintenance  Data 

• 

• 

F.3.3 

Process  Logistics  Data 

• 

• 

F.3.4 

Process  Training  Data 

• 

• 

F.3.5 

Process  RMA  Data 

• 

• 

F.4.0 

Analyze  Data 

F.4.1 

Analyze  Maintenance  Data 

• 

• 

• 

F.4.2 

Conduct  System  Performance  Trending  Analyis 

• 

• 

F.4.3 

Compute  System  Ao/Ai  based  on  RMA  data 

• 

• 

F.4.4 

Conduct  Cost  Analysis 

• 

• 

F.5.0 

Report  Data 

F.5.1 

Generate  System  Assessment  Report 

• 

• 

F.5.2 

Generate  Logistics  Report 

• 

F.5.3 

Generate  System  Status  Report 

• 

• 

F.5.4 

Generate  System  RMA  Report 

• 

F.6.0 

Display  Data 

F.6.1 

Display  Fleet  Support  Information 

• 

F.6.2 

Display  Historical  Fleet  Data 

• 

• 

F.6.3 

Display  Corrective  Maintenance  Information 

• 

• 

F.6.4 

Display  Logistics  Information 

• 

• 

F.6.5 

Display  RMA  Analysis  Data 

• 

• 

F.7.0 

Print  &  Save  Data 

• 

• 

Figure  55.  System  View  of  Operational  Activity  to  System  Function  (SV-5a) 
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D.  PHYSICAL  ARCHITECTURE 


1.  System  Interface  Description  (SV-1) 

As  defined  in  DoDAF  V.2.0,  the  system  interface  description  (SV-1)  addressed 
the  composition  and  interaction  of  systems.  The  SV-1  links  together  the  operational  and 
systems  architecture  models  by  depicting  how  resources  are  structure  and  interact  to 
realize  the  logical  architecture  specified  in  an  OV-2.  Figure  56  depicts  the  composition 
and  interactions  of  the  DAS  with  other  systems  as  previously  defined  in  OV-1  and  OV-2. 
DAS  will  connect  to  other  systems  via  a  Transmission  Control  Protocol/Intemet  Protocol 
(TCP/IP). 


Figure  56.  System  Interface  Description  (SV-1) 
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2.  System  Resource  Flow  Description  (SV-2) 

The  system  resource  flow  description  identifies  the  systems  flow  between  systems 
as  shown  in  Figure  57.  The  interfaces  between  DAS  and  other  systems  are  comprised  of 
internal  and  external  interfaces.  The  internal  interface  is  defined  the  interactions  of  the 
systems  within  NSWC  PHD  physical  boundary.  DAS  interfaces  with  other  NSWC  PHD 
systems  for  display  and  data  storage  through  and  an  unclassified  NMCI  network.  Even 
though  the  scope  of  the  project  was  only  focus  on  unclassified  data,  it  is  considered  that 
the  classified  network  topology  and  system  interface  are  considered  very  similar  to 
unclassified  environment. 


Figure  57.  System  Resource  Flow  Description  (SV-2) 
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E.  ESDS+  ARCHITECTURE 


Based  on  the  results  from  the  AoA  previously  addressed  in  Chapter  III  Section  J, 
it  is  recommended  that  modifying  ESDS  will  be  a  better  solution  than  developing  a  new 
system  based  on  the  gap  analysis,  cost  analysis  and  risk  analysis  that  was  performed.  This 
section  defines  the  augmented  architecture  of  ESDS+,  or  the  extent  of  the  system 
architecture  modifications  that  must  occur  to  the  existing  ESDS,  in  order  to  meet  all  the 
functional  architecture  of  DAS.  In  this  report,  the  functions  that  require  modifications 
and/or  additions  will  be  referred  to  as  augmented  functions.  The  approach  of  defining  the 
ESDS+  architecture  was  based  on  the  gap  analysis  between  the  existing  ESDS  and  DAS 
functional  requirements.  As  previously  defined,  the  five  high  level  functions,  as  shown  in 
Figure  58,  that  are  required  additions  for  ESDS+  are:  1)  obtain  data  from  fleet,  2)  process 
general  information,  3)  process  training  data,  4)  display  fleet  support  data  and  5)  display 
corrective  maintenance  data. 
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Modified  ESDS  Augmented  Functions 
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In  order  to  expand  the  ESDS+  architecture  in  further  detail,  each  defined 
augmented  function  was  decomposed  to  the  lower  level  function.  An  IDEFO  diagram  was 
created  to  show  how  the  inputs  are  converted  to  outputs  among  the  functions.  The 
following  paragraphs  and  figures  will  address  ESDS+’s  functional  decomposition  with  its 
respective  IDEFO  diagram.  It  is  important  to  note  that  ESDS  was  designed  and  developed 
as  an  engineering  and  supportability  analysis  tool  rather  than  a  Distance  Support  tool 
(NSWC  PHD  2009);  therefore  all  functional  gaps  are  mainly  associated  with  fleet 
support. 

1.  Obtain  Data  (F.2.0) 

ESDS  currently  does  not  collect  data  directly  from  the  fleet.  Stakeholders  have 
expressed  the  need  for  DAS  to  collect  remote  assessment  reports,  ships’  system 
performance  data,  and  technical  assistance  reports.  Figure  59  shows  the  functional 
decomposition  of  the  “Obtain  Data  from  Fleet”  function  while  Figure  60  shows  the 
“Obtain  Data  from  Fleet”  functional  interface  diagram. 
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Figure  59.  Augmented  Functions  Obtain  Data  (F.2.0) 
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Figure  60.  Obtain  Data  From  Fleet  IDEFO  (F.2.2) 
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2.  Process  Data  (F.3.0) 

Another  ESDS  functional  gap  was  processing  general  information.  ESDS  does 
not  collect  and  process  general  information  pertaining  to  SMEs  point  of  contact,  ship  and 
system  description,  and  system  configuration  for  instance.  Figure  61  shows  the 
decomposed  “Process  General  Information”  function.  The  functions  that  would  need  to 
be  added  for  ESDS+  are:  1)  “Provide  SME  POC  Information  by  Organization  and 
System,”  2)  “Provide  System  Information  Based  on  a  Hierarchy  Structure,”  3)  “Provide 
Frequently  Asked  Question  Data”  and  4)  “Provide  Blog  and  Forum  Data.”  The  interface 
diagram  is  illustrated  in  Figure  62.  Figure  63  shows  the  decomposed  “Process  Training 
Data”  function.  The  augmented  function  is  “Process  Training  Discrepancy  Data.” 


147 


F.3.0 

Process  Data 

Function 

1 

l 

F.3.1 

F.3.2 

F.3.3 

F.3.4 

F.3.5 

Process  General 
Information 

Process 

Maintenance  Data 

Process  Logistics 
Data 

Process  Tranmg 
Data 

Process  RMA  Data 

Function 

Function 

Function 

Function 

Function 

F.3.1. 1 

F.3.1.2 

F.3.1.3 

F.3. 1.4 

F.3.4. 1 

Provide  SMEPOCmfb 

Provide  system  info  based 

Provide  Frequent 

Provide  Blog  and 

Process  Tranmg 

by  Organizabon/System 

on  Neararchy  structure 

Ask  Question  Data 

Forum  Data 

Descrepancy  Data 

Function 

Function 

Function 

Function 

Function 

Figure  61.  Augmented  Functions  Process  Data  (F.3.0) 
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3.  Display  Data  (F.6.0) 

ESDS  provides  some  information  related  to  fleet  historical  data  concerning 
logistics  and  RMA  data  that  can  be  accessed  via  the  NSWC  PHD  Portal.  ESDS  does  not 
provide  any  information  that  can  be  used  for  self-help  maintenance  support,  such  as  1)  a 
listing  of  SME  point  of  contacts,  2)  ship  and  system  information,  3)  troubleshooting  tips, 
4)  frequently  asked  questions,  5)  equipment  common  failure  items,  nor  6)  forums  where 
Sailors  and  SMEs  can  share  information  related  to  equipment  maintenance.  Figures  64, 
65,  and  66  illustrate  the  augmented  functions  for  displaying  data  that  are  required  for 
ESDS+. 


151 


Fh6hO 


Display  Data 


Function 


R6.3 

F.6.4 

F.6,5 

Display 

Display  Logistics 

Display  RMA 

Corrective  Main.., 

Information 

Analysis  Data 

Function 

Function 

Function 

F.6.3.1 


Display  Historical 
System  Main  ben.,. 

Function 


Figure  64.  Augmented  Functions  Display  Data  (F.6.0) 
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Figure  65.  Display  Fleet  Support  Information  IDEFO  (F.6.1) 
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Figure  66.  Display  Corrective  Maintenance  Information  IDEFO  (F.6.3) 


F.  SUMMARY 

The  last  step  of  the  SE  process  that  the  team  completed  was  to  develop  the 
architecture  for  DAS  and  ESDS+.  “The  ultimate  goal  [of  a  system  architecture]  is  the 
generation  of  information  for  decision  makers  to  determine  what  the  proposed  systems 
are  likely  to  do,  to  compare  these  systems  with  related  current  and  proposed  technology, 
and  to  acquire  appropriate  new  technologies  compatible  or  complementary  with  current 
capabilities”  (Dam  2006,  1).  The  team  used  IDEFO  to  map  how  inputs  are  transformed 
into  outputs  and  the  controls  that  make  it  happen.  The  IDEFO  was  used  to  model  both  the 
functional  and  physical  architectures  of  DAS.  As  a  means  of  describing  the  DAS 
architecture,  a  number  of  DoDAF  products  were  developed.  The  DoDAF  products  were 
tailored  to  this  project  and  thus  only  a  limited  number  of  Operational  Views  and  Systems 
Views  were  produced.  The  DoDAF  Operational  Views  identify  the  tasks  and  activities 
that  need  to  be  accomplished  as  well  as  the  operational  elements  required  to  complete  the 
DAS’  mission.  The  DoDAF  System  Views  depict  the  interconnections  between  software 
and  hardware  required  for  DAS  to  function.  The  architecture  for  ESDS+  was  then 
developed  based  on  the  gap  analysis  that  was  discussed  in  Chapter  III,  the  DoDAF 
products,  and  the  IDEFO  model  developed  for  DAS. 
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V.  CONCLUSION 


A.  SUMMARY 

This  capstone  project  addressed  the  need  for  a  solution  to  improve  the  Navy’s 
current  Distance  Support  capability,  as  the  Navy  and  related  stakeholders  have 
determined  that  an  improved  Distance  Support  capability  is  necessary  and  will  greatly 
benefit  fleet  readiness.  In  order  to  address  the  need  for  improved  Distance  Support,  the 
team  recommends  the  use  of  a  DAS  to  aggregate  and  capture  knowledge.  Furthermore, 
the  team  recommends  implementing  the  DAS  by  improving  ESDS  to  provide  additional 
functionality  and  significantly  enhance  self-help  and  otherwise  improve  Distance  Support 
capabilities.  The  term  “ESDS  Plus”  (ESDS+)  has  been  adopted  to  distinguish  between 
the  current  system  and  the  preferred  system. 

To  guide  the  project,  the  team  answered  the  following  research  questions,  which 
were  developed  to  frame  the  team’s  research  effort: 

•  Why  is  improving  the  Navy’s  Distance  Support  system  important  or 
necessary? 

•  How  do  others  conduct  Distance  Support  and  are  they  effective? 

•  How  do  the  stakeholders  define  an  effective  and  affordable  Distance 
Support  system? 

•  How  can  the  existing  Distance  Support  system  be  improved  or  modified  to 
increase  fleet  readiness  and  reduce  TOC? 

1.  Why  is  improving  the  Navy’s  Distance  Support  system  important  or 
necessary? 

This  research  question  was  important  because  the  answers  were  used  to  develop 
the  following  problem  statement: 

In  recent  years,  the  Navy’s  decision  to  reduce  manning  and  training  with 

the  increased  complexity  of  combat  systems  as  new  programs  emerge 
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have  led  to  a  decline  in  Sailors’  ability  to  operate,  maintain,  and  sustain 
combat  systems  to  the  levels  required  to  meet  mission  readiness 
requirements  (Balisle  2011).  Numerous  Distance  Support  tools  currently 
used  to  respond  to  USN  fleet  combat  system  issues  are  often  slow  and 
ineffective.  The  eventual  technical  solutions  are  often  not  captured  for 
knowledge  retention  and  reutilization,  nor  are  they  available  as  a  self-help 
tool  for  the  war-fighters.  Knowledge  data  that  is  captured  is  difficult  to 
access  and  utilize  in  a  timely  manner.  In  addition,  current  Distance 
Support  tools  used  by  Subject  Matter  Experts  (SME)  to  obtain  and  analyze 
system  performance  metrics  are  manually  intensive  and  limited  in 
capability. 

This  problem  statement  can  be  broken  down  into  the  following  four  sub-problems. 

a.  Current  Distance  Support  Tools  are  often  Slow  and  Ineffective 

The  stakeholders  indicated  that  increasing  the  Distance  Support  capability 
has  become  even  more  important  as  budgets  are  constrained.  The  combat  system 
personnel  aboard  USN  ships  are  tasked  to  have  their  equipment  in  a  mission-ready  state 
at  all  times  when  deployed.  Diagnostics  on  these  complex  systems  can  be  lengthy,  as  can 
the  typical  trouble  call  for  help  from  the  shore -based  technical  support  infrastructure.  To 
improve  the  Distance  Support  process  and  to  avoid  unnecessary  system  down  time  from 
waiting  for  technical  assistance  from  shore  support,  Sailors  can  quickly  and  easily  search 
and  obtain  maintenance  information  via  ESDS+  without  having  to  contact  the  SME. 

b.  Technical  Solutions  are  often  not  Captured  nor  Available  to  the 
Fleet 

Previous  NSWC  PHD  Distance  Support  studies  and  already  completed 
surveys  revealed  that  most  technical  issues  are  being  responded  to  on  a  case  by  case  basis 
in  manner  that  is  dependent  upon  the  assigned  SME’s  knowledge  of  the  system.  Any 
solutions  discovered  may  not  be  recorded  for  a  technical  community  forum  to  be  used  by 
other  end  users.  ESDS+  will  address  this  problem  by  collecting  data  directly  from  the 
fleet  and  displaying  the  data  in  clear  and  concise  reports.  The  ability  to  extract  and 
display  information  automatically  could  significantly  increase  Sailors’  ability  conduct 
maintenance  using  a  self-help  tool.  Some  examples  of  the  topics  that  would  be  available 
are  1)  a  listing  of  SME  points  of  contact,  2)  ship  and  system  information,  3) 
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troubleshooting  tips,  4)  frequently  asked  questions,  5)  equipment  common  failure  items, 
or  6)  forums  where  Sailors  and  SMEs  can  share  information  related  to  equipment 
maintenance. 


c.  Captured  Data  is  Difficult  to  Access  and  Utilize 

Presently,  NSWC  PHD  is  providing  Distance  Support  utilizing  tools  such 
as  prognostics  and  remote  monitoring,  but  the  methodology  used  is  based  on  what  was 
developed  for  individual  systems,  meaning  the  content  and  tools  are  hosted  on  system- 
exclusive  servers.  For  Sailors  to  gain  access  to  the  data,  special  permission  is  typically 
required.  As  a  data  aggregator,  ESDS+  would  interface  with  all  of  the  existing  Distance 
Support  tools  so  data  could  be  readily  available  and  accessed  efficiently  by  all  Sailors  and 
SMEs.  Also,  by  augmenting  the  five  ESDS  functions,  the  users  would  be  able  to  obtain 
more  informative  reports  that  are  user-friendly. 

d.  Current  Distance  Support  Tools  are  Manually  Intensive  and 
Limited  in  Capability 

When  SMEs  assist  Sailors  in  troubleshooting  efforts,  the  primary  vehicle 
of  communication  is  usually  e-mail.  Thus,  Sailors  are  required  to  manually  provide  all 
metrics  to  the  SMEs.  This  leads  to  limits  in  capability,  as  well  as  creates  room  for  errors 
and  miscommunication.  ESDS+  would  automatically  obtain  data  such  as  ships’  system 
performance  and  trending  analysis  data  directly  from  the  fleet,  which  would  eliminate  the 
need  to  manually  enter  data  to  obtain  help. 

2.  How  do  others  conduct  Distance  Support  and  are  they  effective? 

This  capstone  project  examined  other  organizations  to  learn  if  they  experience  the 
same  problems  NSWC  PHD  does  with  respect  to  Distance  Support,  and  how  they  judge 
success.  With  regards  to  USN  Distance  Support,  the  focus  is  fixing  a  deployed  asset.  If  a 
ship  cannot  perform  a  particular  mission,  the  ship  itself  most  likely  cannot  be  replaced 
quickly,  ft  is  because  of  this  paradigm  that  knowledge  is  not  captured  from  events  and  the 
Distance  Support  system  does  not  currently  meet  the  goals  of  the  stakeholders. 
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3. 


How  do  the  stakeholders  define  an  effective  and  affordable  Distance 
Support  system? 


The  team  applied  an  SE  approach  to  clearly  define  the  architecture  that  would  be 
an  effective  and  affordable  Distance  Support  system.  The  team  started  by  consulting  past 
NSWC  PHD  Distance  Support  surveys  and  studies  to  clearly  define  needs.  The  result  of 
the  analysis  showed  that  NSWC  PHD  needed  to  improve  Distance  Support  data 
aggregation  and  knowledge  reutilization  capabilities  in  order  to  provide  more  effective 
Distance  Support  to  the  fleet.  To  do  this,  the  needs  analysis  suggested  that  the  solution 
needed  to  be  easily  accessible,  provide  high  quality  information  that  was  current, 
relevant,  accurate,  reliable  and  complete,  the  data  should  be  well  organized  and  displayed 
and/or  reported  as  needed.  These  needs  were  used  to  develop  a  CONOP  (at  a  very  high 
level),  to  identify  the  stakeholders,  and  to  determine  how  the  stakeholders  would 
communicate  with  their  system  provided  as  a  solution.  After  completion  of  the  initial 
research,  the  team  scoped  the  project  to  the  data  aggregation  process,  which  was  named 
DAS,  to  ensure  the  project  could  be  completed  within  the  time  allowed  since  the  data 
aggregation  process  itself  is  quite  complex  and  software  intensive. 

Once  the  needs  were  defined,  a  requirements  analysis  was  conducted  to  identify 
the  operational,  functional,  physical  and  performance  requirements  of  the  DAS.  The 
requirements  fell  into  three  major  categories:  1)  Characteristics,  2)  Design  and 
Construction,  and  3)  Component  Level  requirements.  Together,  these  requirements  could 
be  used  to  translate  the  stakeholders’  needs  into  a  set  of  system  operational,  maintenance 
and  support  concepts.  The  team  used  Vitech’s  CORE®  software  suite  to  input  the  DAS 
requirements,  beginning  the  development  of  the  DAS  architecture.  DAS  functions  were 
then  identified.  The  functions  were:  Provide  External  Interface,  Obtain  Data,  Process 
Data,  Analyze  Data,  Report  Data,  Display  Data,  and  Print  and  Save  Data.  The  functions 
were  traced  to  the  DAS  requirements  and  design  criteria.  This  tracing  helped  identify  the 
necessary  resources  required  for  DAS  support  and  operation. 

The  team  solicited  preferences  from  stakeholders  in  order  to  prioritize  and  further 
define  the  system  requirements  and  system  functions.  By  focusing  on  higher  level  data 
integration  system  requirements  and  functions,  the  team  conducted  an  AoA  to  identify 
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alternatives  and  this  included  modifying  existing  systems  that  could  satisfy  all  system 
requirements.  Unfortunately,  the  team  was  unable  to  identify  an  existing  system  that 
could  meet  all  requirements,  which  meant  that  some  development  would  be  required.  To 
minimize  development,  the  team  conducted  a  gap  analysis  of  the  existing  systems,  and 
determined  that  among  the  possible  alternatives,  ESDS  contained  the  least  number  of 
functional  gaps. 

Since  cost  was  a  critical  determining  factor,  the  team  compared  the  cost  of 
ESDS+  to  building  an  entirely  new  system.  The  team  focused  the  cost  analysis  on 
development  costs  of  the  two  alternatives,  as  it  was  determined  that  life  cycle  costs, 
disposal  costs,  and  savings  would  be  relatively  similar  between  both  options.  COSYSMO 
2.0  software  was  used  to  estimate  and  compare  the  engineering  effort  that  would  be 
required  to  develop  ESDS+  or  a  brand  new  system.  The  cost  analysis  revealed  that 
ESDS+  was  the  less  expensive  solution,  estimating  that  the  development  effort  of  ESDS+ 
would  cost  approximately  40%  of  the  total  development  cost  required  to  build  a  new 
system.  To  further  analyze  the  two  alternatives,  Expert  COSYSMO  was  used  to  conduct 
a  cost  risk  analysis.  On  a  scale  of  zero  to  702,  the  results  showed  that  ESDS+  had  a  risk 
level  of  44.7  and  the  new  system  had  a  risk  level  of  45.7,  which  shows  that  both 
alternatives  are  equally  risky. 

4.  How  can  the  existing  Distance  Support  system(s)  be  improved  or 
modified  to  increase  fleet  readiness  and  reduce  total  ownership  costs? 

Based  on  the  team’s  analysis,  ESDS+  was  therefore  recommended  as  the 
preferred  alternative.  This  turned  out  to  be  good  news,  because  a  significant  amount  of 
resources  have  already  been  invested  in  developing  ESDS.  ESDS  is  currently  in  use  at 
the  NSWC  PHD  Command,  but  only  on  a  limited  basis.  By  adding  self-help  and  other 
missing  functionality  to  ESDS,  Distance  Support  capabilities  will  be  significantly 
enhanced. 
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ESDS+  is  the  recommended  solution  because  it  also  answers  the  team’s  problem 
statement,  which  was  used  to  structure  this  study.  ESDS+  seeks  to  be  a  user-friendly 
efficient  tool  that  will  capture  knowledge  through  multiple  available  data  sources  for 
maintenance,  performance  and  logistics  that  could  be  utilized  in  a  timely  manner  to  make 
Distance  Support  a  more  responsive  and  effective  product. 

B.  AREAS  FOR  FUTURE  RESEARCH 

There  are  many  more  opportunities  to  continue  improving  the  USN  Distance 
Support  capability,  further  the  development  and  implementation  of  the  DAS,  and 
examine  the  other  many  components  of  the  overall  function  of  providing  Distance 
Support.  For  future  work,  the  team  recommends  that  the  user  interface  function  of  the 
DAS  be  expanded  to  increase  the  usability  of  the  aggregated  data.  In  addition,  the 
following  list  provides  examples  of  areas  that  need  further  research  and  development,  and 
could  be  conducted  in  other  capstone  projects  at  NPS: 

•  Complete  development,  testing,  and  evaluation  of  the  ESDS+ 

•  Expand  on  the  user  interface  function 

•  Improve  the  content  and  quality  of  the  data  sources 

•  Improve  knowledge  capturing  systems,  methods,  and  techniques 

•  Measure  and  improve  data  access  times 

•  Improve  connectivity  to  the  DAS,  especially  while  deployed 

•  Expand  the  DAS  beyond  maintenance  to  include  areas  such  as  training, 
logistics,  personnel,  and  mission  readiness 

•  Expand  the  DAS  to  included  classified  information  sharing 
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•  Conduct  unlimited  analysis  of  the  data  produced  by  the  DAS  to  increase 
effectiveness  and  efficiencies  related  to  producing,  operating,  and 
maintaining  Navy  weapons  systems  and  related  functions,  i.e.,  improve 
equipment  reliability  and  increase  operational  availability 

•  Refine  the  DAS  architecture. 

Finally,  the  team  strongly  encourages  the  stakeholders  to  go  forward  with  the  planning 
and  budgeting  to  develop  ESDS+  as  the  recommended  solution  for  improving  Distance 
Support  and  enabling  the  fleet  to  maintain  the  highest  state  of  mission  readiness  while 
minimizing  TOC. 
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APPENDIX  A.  SYSTEM  REQUIREMENTS 


The  Table  16  lists  all  requirements  the  Distance  Support  team  derived  from  past 
Distance  Support  studies. 


Number 

Name 

Description 

R.0.0 

Data  Aggregation  System 

(DAS)  Specific 

Requirements 

The  system  shall  display  status  on  installed 

engineering  alterations  and  engineering 

alterations  under  development  or  planned  for 

development 

R.1.0 

Characteristics 

The  system  shall  display  status  on  installed 

engineering  alterations  and  engineering 

alterations  under  development  or  planned  for 

development 

R.1.1 

Performance 

The  system  shall  display  status  on  installed 

engineering  alterations  and  engineering 

alterations  under  development  or  planned  for 

development 

R.l.1.1 

External  Interface 

This  system  shall  be  capable  of  interface 

with  other  systems  including  human 

interface  and  databases  to  collect  and  provide 

necessary  data  to  perform  all  the  functions. 

R.1.1. 1.1 

System  Interface 

The  system  shall  have  the  capability  to 

interface  with  other  systems  and  databases 

within  fleet  support  infrastructure  to 

aggregate  the  data 
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Number 

Name 

Description 

R.l. 1.1.2 

User  Interface 

The  system  shall  be  accessible  via  Port 

Hueneme  Division  (PHD)  Portal 

R.l.1.2 

Fleet  Maintenance 

Support  Data  and  Metrics 

Group  Title 

R.l. 1.2.1 

Display  a  list  of 

system/subsystem  on  each 

platform 

The  system  shall  provide  a  list  of 

system/subsystem  on  each  platform 

R.  1.1. 2.2 

Display  Subject  Matter 

Expert  (SME)  contact 

information  for  each 

system/  subsystem 

The  system  shall  display  SME  contact 

information  for  each  system/subsystem 

R.  1.1. 2.3 

Display  a  list  of  Open 

Casualty  Reports 

(CASREP),  Trouble 

Tickets,  and  Help  Desk 

items  open  for  a  specific 

ship  or  an  entire  Strike 

Group 

The  system  shall  display  a  list  of  Open 

CASREP,  Trouble  Tickets,  and  Help  Desk 

items  open  for  a  specific  ship  or  an  entire 

Strike  Group 

R.l. 1.2.3. 1 

Search  and  Display 

CASREP  data  based  on 

category,  ship,  element, 

system  subsystem, 

symptom,  status 

The  system  shall  be  able  to  search  and 

display  the  CASREP  data  based  on  category, 

ship,  element,  system  subsystem,  symptom, 

and  status 
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Number 

Name 

Description 

R.  1.1. 2.4 

Display  Area  of 

Responsibility  (AOR) 

requirements/Standing 

Orders  (Classified)  for  all 

platform  in  a  Strike  Group 

The  system  shall  display  AOR 

requirements/Standing  Orders  (Classified) 

for  all  platform  in  a  Strike  Group 

R.  1.1. 2.5 

Display  outstanding/open 

CASREP,  2-Kilo,  and 

Technical  Assist  Visit 

Request 

The  system  shall  display  outstanding/open 

CASREP,  2-Kilo,  and  Technical  Assist  Visit 

Request 

R.  1.1. 2.6 

Display  Technical  Assist 

Visit  Reports  (TAVRs)  by 

system 

The  system  shall  display  TAVRs  by  system 

R.  1.1. 2.7 

Display  the  past  and 

current  In-Service 

Engineering  Agent  (ISEA) 

investigations  at  the 

systems,  equipment,  and 

Lowest  Replaceable  Unit 

(LRU)  levels 

The  system  shall  display  the  past  and  current 

ISEA  investigations  at  the  systems, 

equipment,  and  LRU  levels 

R.  1.1. 2.8 

Display  status  on  installed 

engineering  alterations 

and  engineering 

alterations  under 

development  or  planned 

for  development 

The  system  shall  display  status  on  installed 

engineering  alterations  and  engineering 

alterations  under  development  or  planned  for 

development 

R.  1.1. 2.9 

Display  unclassified 

CASREP  metrics 

The  system  shall  display  unclassified 

CASREP  metrics 
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Number 

Name 

Description 

R.l.  1.2.10 

Display  known  problems 

(issues  seen  by  other 

Ships)  and  frequently 

asked  questions 

The  system  shall  display  known  problems 

(issues  seen  by  other  Ships)  and  frequently 

asked  questions 

R.l. 1.2.11 

Display  lessons  learned 

and  past 

troubleshooting/problem 

resolution  information 

The  system  shall  display  lessons  learned  and 

past  troubleshooting/problem  resolution 

information 

R.l. 1.2.12 

Display  authorized 

detailed  troubleshooting 

procedures  for  common 

equipment  failures 

The  system  shall  display  authorized  detailed 

troubleshooting  procedures  for  common 

equipment  failures 

R.l. 1.2.13 

Display  Command  Issues 

Management  (CIM) 

information  (status) 

The  system  shall  display  CIM  information 

(status) 

R.l. 1.2.14 

Display  a  ship’s  combat 

system  software 

configuration  (including 

the  software  version  of 

each  sub-system) 

The  system  shall  display  a  ship’s  combat 

system  software  configuration  (including  the 

software  version  of  each  sub-system) 
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Number 

Name 

Description 

R.l. 1.2.15 

Display  Board  of 

Inspection  and  Survey 

(INSURY)  and 

Availability  schedules  and 

type,  for  instance  Selected 

Restricted  Availability 

(SRA),  Docking  or  Dry¬ 
docking  Selected 

Restricted  Availability 

(DSRA),  or  Regular 

Overhaul  (ROH),  for  ships 

and  provide  a  graphical 

representation  of  the 

INSURV  and  Availability 

schedules  of  an  entire 

Strike  Group 

The  system  shall  display  INSURV  and 

Availability  schedules  and  type  like  SRA, 

DSRA,  and  ROH  for  ships  and  provide  a 

graphical  representation  of  the  INSURV  and 

Availability  schedules  of  an  entire  Strike 

Group 

R.l. 1.2.16 

Display  common 

equipment  failures  and 

corrective  action  taken  per 

element/system/subsystem 

/components 

The  system  shall  display  common  equipment 

failures  and  corrective  action  taken  per 

element/ system/subsystem/ components 

R.l. 1.2.17 

Display  a  user-selectable 

range  of  the  top 

equipment  taking  the 

longest  time  to  repair 

The  system  shall  display  a  user-selectable 

range  of  the  top  equipment  taking  the  longest 

time  to  repair 
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Number 

Name 

Description 

R.l. 1.2.18 

Display  a  user-selectable 

range  of  the  top  LRUs 

with  the  highest  failure 

rates  for  equipment  in  a 

Pareto  diagram  for 

specific  systems 

The  system  shall  display  a  user-selectable 

range  of  the  top  LRUs  with  the  highest 

failure  rates  for  equipment  in  a  Pareto 

diagram  for  specific  systems 

R.l. 1.2.19 

Display  (using  a  Pareto 

diagram)  a  user-selectable 

range  of  the  top  high- 

usage  rate  LRUs  for 

specific  systems 

The  system  shall  display  (using  a  Pareto 

diagram)  a  user-selectable  range  of  the  top 

high-usage  rate  LRUs  for  specific  systems 

R.  1.1. 2.20 

Display  manning  level  per 

work  center  per  ship 

The  system  shall  display  manning  level  per 

work  center  per  ship 

R.l. 1.2.21 

Display  manning 

qualification  to  conduct 

mission  per  work  center 

per  ship  per  mission 

The  system  shall  display  manning 

qualification  to  conduct  mission  per  work 

center  per  ship  per  mission 

R.  1.1. 2.22 

Display  performance 

trends  per 

element/system/subsystem 

The  system  shall  display  performance  trends 

per  element/system/subsystem 

R.  1.1. 2.23 

Display  maintenance  work 

hours  at  the 

ship/ system/cabinet/LRU 

level 

The  system  shall  display  maintenance  work 

hours  at  the  ship/system/cabinet/LRU  level 

R.  1.1. 2.24 

Display  past  and  current 

technical  assistance  efforts 

requested  by  the  fleet 

The  system  shall  display  past  and  current 

technical  assistance  efforts  requested  by  the 

fleet 
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Number 

Name 

Description 

R.  1.1. 2.25 

Correlate  Preventive 

Maintenance  (PMS) 

history  with  material 

readiness  or  equipment 

failures  and  display  the 

results 

The  system  shall  correlate  PMS  history  with 

material  readiness  or  equipment  failures  and 

display  the  results 

R.  1.1. 2.26 

Display  the  composition 

(unclassified)  and  planned 

deployment  dates 

(Classified)  for  current 

and  future  Strike  Groups 

and  others  deployed  as 

identified  by  the  Fleet 

Commanders 

The  system  shall  display  the  composition 

(unclassified)  and  planned  deployment  dates 

(Classified)  for  current  and  future  Strike 

Groups  and  others  deployed  as  identified  by 

the  Fleet  Commanders 

R.  1.1. 2.27 

Display  Combat  System 

(CS)  Safety  Issues  per 

Ship  and  historical/trends 

data 

The  system  shall  display  CS  Safety  Issues 

per  Ship  and  historical/trends  data 

R.  1.1. 2.28 

Display  current 

configuration  and  past 

configurations  up  to  5 

years  by  ship  by  system 

The  system  shall  display  current 

configuration  and  past  configurations  up  to  5 

years  by  ship  by  system 

R.  1.1. 2.29 

Display  an  average  time- 

open  bar  chart  for  2-Kilo 

The  system  shall  display  an  average  time- 

open  bar  chart  for  2-Kilo 
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Number 

Name 

Description 

R.  1.1. 2.30 

Display  Mean  Time  To 

Repair  (MTTR)  metrics 

using  data  from  2-Kilo 

Maintenance  Man  Hours 

(MMH)  and  repair  time 

information 

The  system  shall  display  MTTR  metrics 

using  data  from  2-Kilo  MMH  and  repair  time 

information 

R.l. 1.2.31 

Display  MTTR  Data  from 

Material  Readiness 

Database  (MRDB) 

The  system  shall  display  MTTR  Data  from 

MRDB 

R.  1.1. 2.32 

Display  Mean  Time 

Between  Equipment 

Mission  Critical  Events 

(MTB(EMCE))  and  Mean 

Time  Between  Equipment 

Malfunction  Events 

(MTB(EME))  or  obtain 

and  display  data  from 

MRDB 

The  system  shall  display  MTB  (EMCE)  and 

MTB(EME)  or  obtain  and  display  data  from 

MRDB 

R.l.  1.3 

Logistics  Data 

Group  Title 

R.l. 1.3.1 

Display  Allowance  Part 

List  (APL)  of  all  systems 

The  system  shall  display  APL  of  all  systems 

R.l. 1.3.2 

Display  a  user-selectable 

range  of  the  normalized 

top  LRU  with  the  highest 

cost  by  system-year  or 

cabinet-year 

The  system  shall  display  a  user-selectable 

range  of  the  normalized  top  LRU  with  the 

highest  cost  by  system-year  or  cabinet-year 
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Number 

Name 

Description 

R.l. 1.3.3 

Provide  high  demand  and 

high  cost  parts  per 

element/system/subsystem 

/LRU 

The  system  shall  generate  and  display  high 

demand  and  high  cost  parts  per 

element/system 

R.l. 1.3.4 

Provide  ship  class  and 

ship  baseline  Cost  Report 

The  system  shall  generate  and  display  cost 

reports  based  on  ship  class,  ship  baseline, 

and  individual  ship 

R.l. 1.3.5 

Provide  Cost  Reports 

based  on 

system/  subsystem 

The  system  shall  generate  and  display  Cost 

Reports  for  each  system/subsystem 

R.l. 1.3.6 

Compare  and  display 

Mean  Logistics  Delay 

Time  (MLDT)  for  any 

LRU  at  ship/system  level 

The  system  shall  display  the  comparison 

chart  of  MLDT  for  any  LRU  at  ship/system 

level  where  data  is  available 

R.l. 1.3.7 

Display  parts  that  have 

failed  in  the  past  quarter 

above  a  specified 

threshold  in  three 

categories 

The  system  shall  display  parts  that  have 

failed  in  the  past  quarter  above  a  specified 

threshold  in  three  categories 

R.l. 1.3.8 

Display  technical 

publications  (bulletins) 

developed  by  shore 

support  activities,  such  as 

ISEA  and  Regional 

Maintenance  Center 

(RMC) 

The  system  shall  display  technical 

publications  (bulletins)  developed  by  shore 

support  activities,  such  as  ISEA  and  RMC 
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Number 

Name 

Description 

R.l.  1.3.9 

Display  the  number  of 

failures  of  LRUs  at  the 

ship  baselines,  and  class 

levels 

The  system  shall  display  the  number  of 

failures  of  LRUs  at  the  ship  baselines,  and 

class  levels 

R.  1.1.3.10 

Display  supply  inventory, 

sparing  info,  for  any  user- 

specified  part  by  National 

Item  Identification 

Number  (NUN) 

The  system  shall  display  supply  inventory, 

sparing  info,  for  any  user-specified  part  by 

NUN 

R.l. 1.3. 11 

Display  Diminishing 

Manufacturing  Sources 

(DMS)  data  by 

system/  equipment/LRU 

The  system  shall  display  DMS  data  by 

system/equipment/LRU 

R.l. 1.3. 12 

Display  part  numbers  and 

part’s  usage  based  on 

historical  data 

The  system  shall  display  part  numbers  and 

its  usage  based  on  historical  data  for  the  last 

5  years 

R.l.  1.4 

Training  Data 

Group  Title. 

R.l. 1.4.1 

Display  Training 

Discrepancies  from  Ship 

Reports,  Technical  Assist 

Visit  Report,  On-Site 

Training  Report,  trip 

report,  and  Availability 

report 

The  system  shall  display  Training 

Discrepancies  from  Ship  Reports,  Technical 

Assist  Visit  Report,  On-Site  Training  Report, 

trip  report,  and  Availability  report 

R.  1.1. 4.2 

Display  training 

deficiencies  CASREP, 

and  2-Kilo  reports 

The  system  shall  display  training 

deficiencies  from  CASREP  and  2-Kilo 

reports 
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Number 

Name 

Description 

R.l.1.5 

Reliability, 

Maintainability,  and 

Availability  (RMA) 

Analysis  Data 

Group  Title 

R.l.  1.5.1 

Display  RMA  drivers 

from  individual  ship,  ship 

baseline,  Strike  Group, 

and  Warfare -Area  levels 

The  system  shall  display  RMA  drivers  from 

individual  ship,  ship  baseline,  Strike  Group, 

and  Warfare- Area  levels 

R.l.  1.5.2 

Display  an  assessment  of 

system/  subsystem 

performance 

The  system  shall  collect  data  from  ship 

readiness  reporting  such  as  Maintenance 

Figure  of  Merit  (MFOM)  and  Operational 

Readiness  Test  System  Tech  Assist  Remote 

Support  (ORTSTARS)  to  assess  and  display 

the  status  of  system/subsystem  with 

Red/Y ellow/Green  indicators  based  on 

system/subsystem  specifications  or  user- 

defined  threshold 

R.l. 1.5.3 

Display  Operational 

Availability  (Ao),  Mean 

Time  Between  Failure 

(MTBF),  and  Mean  Down 

Time  (MDT)  data  per  ship 

baseline 

The  system  shall  display  Ao,  MTBF,  and 

MDT  data  per  ship  baseline 

R.  1.1. 5.4 

Display  unclassified  and 

classified  MFOM 

indicators 

The  system  shall  display  unclassified  and 

classified  MFOM  indicators 
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Number 

Name 

Description 

R.l.1.6 

Reports 

The  system  shall  be  designed  to  allow  the 

user  to  generate,  save,  and  print  the  reports  to 

a  file  with  the  standard  format  such  as 

Acrobat  Portable  Document  Format  (PDF)  or 

Microsoft®  Office  (Word,  Excel)  from  the 

web  pages  where  the  data  can  be  selected 

and  filtered  by  user  defined 

R.1.2 

Physical  Characteristics 

Group  Title 

R.  1.2.1 

Human  System 

Integration 

The  system  shall  be  designed  and  tested  to 

satisfy  human  engineering  design 

requirements  and  standards  included  in  but 

not  limited  to  the  latest  version  of  MIL-STD- 

1472F. 

R.  1.2.2 

Size 

The  major  components  that  are  selected  for 

the  system  shall  support  rack  mount 

installation 

R.1.3 

Reliability 

The  system  shall  be  designed  with 

redundancy  capability  which  is  capable  of 

supporting  the  Ao  of  90% 

R.1.4 

Maintainability 

The  system  shall  be  designed  to  support 

hardware  and  software  maintenance  where 

MTTR  is  less  than  1  hour  and  the  completed 

reload  will  take  no  more  than  20  minutes. 

R.1.5 

Environment  Condition 

The  system  shall  be  designed  to  operate  in  a 

normal  laboratory  environment  conditions. 

R.2.0 

Design  and  Construction 

Group  Title 
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Number 

Name 

Description 

R.2.1 

Data  Collection 

The  system  shall  be  designed  to  collect  data 

either  by  manually  enter  data  from  user 

interface  or  data  push/pull  from  external  file 

or  database 

R.2.2 

Data  Reporting 

The  system  shall  be  designed  to  generate  and 

display  data  as  specified  in  section  1 . 1 

R.2.3 

Navy  Marine  Corps 

Intranet  (NMCI) 

Compliance 

The  system  shall  be  designed  to  comply  with 

NMCI 

R.2.4 

Print  and  Save 

The  system  shall  have  the  capability  to  Print 

and  Save  the  data 

R.3.0 

Component  Level 

Requirements 

Group  Title 

R.3.1 

Hardware 

The  system  shall  use  Commercial  Off-the- 

Shelf  (COTS)  hardware  that  capable  to 

support  the  design  characteristics  defined  in 

section  1.0 

R.3.2 

Software 

The  system  shall  use  COTS  software  that 

capable  to  support  the  design  characteristics 

defined  in  section  1.0 

Table  16.  System  Requirements 
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APPENDIX  B.  SYSTEM  FUNCTIONS 


This  section  documents  the  system  functions  artifacts  that  were  developed  and 
generated  from  CORE®.  Table  17  provides  a  list  of  all  system  functions  that  were 
derived  from  the  requirements  analysis.  Figures  67,  68,  69,  70,  71,  and  72  show  DAS 
functional  hierarchy  in  greater  detail.  Figures  73,  74,  75,  76,  77,  and  78  illustrate  DAS 
functional  IDEFO  diagrams.  Figure  79  shows  the  mapping  requirements  to  system 
functions  analysis  results,  and  Table  18  lists  all  of  the  data  exchanges  that  occur  between 
all  of  the  DAS  functions. 


Number 

Name 

Description 

F.O 

Provide  Data  Aggregation 
Capability 

Group  Title.  The  capability  of  aggregating  data 
from  numerous  existing  Distance  Support 
sources,  exporting  data  to  the  fleet  to  promote 
self-help,  and  exporting  data  to  help  facilitate 
trend/failure  analysis  opportunities. 

F.1.0 

Provide  External  Interface 

Group  Title.  Provide  communication  with  the 
external  systems. 

F.1.1 

Execute  System  Interface 

Establish  network  connection 

F.2.0 

Obtain  Data 

Group  Title.  Obtain  data  from  the  external 
systems. 

F.2.1 

Obtain  Data  from  User 

Inputs 

Users  input  data  into  system  database  and  web 
pages 

F.2.1.1 

Receive  Data  via  Web  Form 

Data  is  entered  by  user  via  a  Web  Form 

F.2.1. 2 

Import  and  Format  Data 
Entered  by  User 

User  enter  data  directly  into  the  system  either 
by  using  a  form  or  a  spreadsheet 

F.2.2 

Obtain  Data  from  Fleet 

Recorded  System  Performance  Data  is 
downloaded  from  ship  either  manually  or 
automatic. 
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F.2.2.1 

Import  Data  from  Remote 
Assessment  Report 

Import  data  from  Assessment  Report 

F.2.2.2 

Extract  Data  from  Ship’s 

Data  Recording 

Extract  data  from  data  recording  transferred 
from  ship  to  shore  via  SIPRNET 

F.2.2.3 

Import  Fleet  Tech  Assist 

Data 

Obtain  Tech  Assist  Data  from  the  following 
database:  Command  Issues  Management 
(CIM),  Global  Distance  Support  Center 
(GDSC)  Remedy,  Trip  Report,  and  SIPRNET 
CHAT 

F.2.2.4 

Import  Fleet  Data  from  On- 
Site  Assessment 

Import  Data  from  the  Board  of  Inspection  and 
Survey  (INSURV)  or  Chief  of  Naval 

Operations  (CNO)  Availability 

F.2.3 

Obtain  Data  from  Fleet 
Support  Infrastructure 

Data  is  collected  through  the  Fleet  Support 
Infrastructure  database:  Sailor  To  Engineer 
(S2E) ,  GDSC  Remedy,  CIM,  Aegis  Combat 
System  Reliability  Maintainability  and 
Supportability  Database  (ACSRMS),  Aegis 
Configuration  Control  and  Engineering  Status 
System  (ACCESS),  Maintenance  Figure  of 
Merit  (MFOM),  Material  Readiness  Database 
(MRDB),  NAVSEA  Logistics  Center  (NSLC) 
Maintenance  and  Material  Management  (3M), 
Federal  Logistics  Data  (FEDLOG), 
Configuration  Data  Managers  Database-Open 
Architecture  (CDMD-OA),  and  so  on 

F.2.3.1 

Collect  Fleet  Maintenance 
Data 

Collect  Ship’s  Report  Maintenance  Data 

F.2.3. 1.1 

Import  Fleet  Maintenance 
Action  Data 

Collect  data  from  3M  database 

F.2.3.2 

Collect  Fleet  Logistics  Data 

Collect  fleet  logistics  data  such  as  part  usages, 
part  inventory,  and  requisition  information. 

F.2.3.2.1 

Import  Parts/Supplies  Data 

Import  parts/supplies  data  from  NSLC  and 

Naval  Supply  Systems  Command  (NAVSUP) 

F.2.3.2. 2 

Import  Parts  Inventory  Data 

Import  parts  inventory  data 
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F.2.3.3 

Collect  Fleet  Training 
Discrepancy  Data 

Collect  fleet  personnel  training  discrepancy 
data 

F.2.3.4 

Collect  Fleet  Reliability, 
Maintainability,  and 
Availability  (RMA)  Data 

Collect  fleet  RMA  data 

F.3.0 

Process  Data 

Group  Title.  Process  collected  data. 

F.3.1 

Process  General 

Information 

Process  and  Filter  the  data  into  different 
categories. 

F.3.1.1 

Provide  Subject  Matter 
Expert  (SME)  Point  of 
Contact  (POC)  info  by 
Organization/System 

Provide  a  list  of  the  SME  POCs  filtered  by 
systems  that  they  support  and  by  organization 
(i.e.,  John  Smith,  NSWC  PHD,  SPY-1A 
RADAR,john.smith@navy.mil,  (805)  228- 
1234) 

F.3.1.2 

Provide  system  info  based 
on  hierarchy  structure 

Listing  the  system  information  based  on 
hierarchy  structure  below: 

-Platform  (i.e.,  CG/DDG  or  DDG1000) 

-Segment  (i.e.,  Combat  System,  Hull, 
Mechanical  and  Electrical  (HM&E), 

Command,  Control,  or  Communications, 
Computers  &  Intelligence  (C4I)) 

-Element  (i.e.,  SPY,  Command  and  Decision 
(C&D),  Weapon  Control  System  (WCS), 

Engine,  or  Navigation) 

-System  (i.e.,  Transmitter,  Power  Generator,  or 
Display) 

-Subsystem 

-Component 

F.3.1. 3 

Provide  Frequent  Ask 
Question  (FAQ)  Data 

Provide  FAQ  Data 

F.3.1.4 

Provide  Blog  and  Forum 

Data 

Provide  Blog  and  Forum  Data  shared  by  fleet 
personnel  and  fleet  support  agents 

F.3.2 

Process  Maintenance  Data 

Process,  filter,  and  categorize  the  maintenance 
data 

F.3.3 

Process  Logistics  Data 

Process,  filter,  and  categorize  the  logistics  data 
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F.3.4 

Process  Training  Data 

Process,  filter,  and  categorize  the  training  data 

F.3.5 

Process  RMA  Data 

Process,  filter,  and  categorize  the  RMA  data 

F.4.0 

Analyze  Data 

Group  Title.  Analyzing  and  updating  the  data 

F.4.1 

Analyze  Maintenance  Data 

Analyze  the  maintenance  data 

F.4.2 

Conduct  System 

Performance  Trending 
Analysis 

Analyze  and  conduct  the  system  performance 
trending  Analysis 

F.4.3 

Compute  System 

Operational  Availability 
(Ao)/Inherent  Availability 
(Ai)  based  on  RMA  Data 

Analyze  and  compute  the  system  Aq/A,  based 
on  the  RMA  data 

F.4.4 

Conduct  Cost  Analysis 

Conduct  Cost  Analysis 

F.5.0 

Report  Data 

Group  Title.  Generate  Reports 

F.5.1 

Generate  System 

Assessment  Report 

Generate  reports  based  on  the  data  collected 
from  Tech  Assists,  remote  monitoring,  or 
system  assessment.  The  system  will  have  the 
ability  to  generate  the  assessment  reports  either 
by  automatically  or  manually 

F.5.2 

Generate  Logistics  Report 

Generate  reports  that  associated  with  logistics 
such  as  supplies  inventories,  Part  Usages,  and 
high  cost  failure  items 

F.5.3 

Generate  System  Status 
Report 

Generate  reports  based  on  the  ship’s  reported 
system  status 

F.5.4 

Generate  System  RMA 
Report 

Generate  reports  based  on  RMA  analysis,  such 
as  Ao,  Mean  Time  Between  Failures  (MTBF), 
and  Mean  Time  To  Repair  (  MTTR) 

F.6.0 

Display  Data 

Group  Title.  Display  data  via  NSWC  PHD 
WebPages 
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F.6.1 

Display  Fleet  Support 
Information 

Display  in  website  the  following  general 
information:  In-Service  Engineering  Agent 
(ISEA)  POCs  (names,  phone  number,  e-mail)  - 
Hierarchical  structure  system  information 
based  on  ship  class,  element  (Combat  System 
(CS),  C4I,  HM&E) 

F.6.1.1 

Display  FAQ,  Blog  and 
Forum  data 

Display  consolidated  data  relative  to  FAQ, 

Blog,  and  Forum  posted  by  fleet  personnel  and 
fleet  support  agents 

F.6.1. 2 

Display  SME  POC  Info 

Display  SME  POCs 

F.6.1. 3 

Display  Ship  and  System 

Info 

Display  ship  and  system  information 

F.6.2 

Display  Historical  Fleet 

Data 

Display  historical  Fleet  data  including  the 
information  below: 

-Number  of  Casualty  Report  (CASREP)  per 
ship  per  year 

-Current  Open  and  Closed  CASREP 

F.6.3 

Display  Corrective 
Maintenance  Information 

Display  information  to  assist  ship  force  to 
conduct  corrective  maintenance  based  on 
sy stem/ equipment  hierarchy.  Data  include 
Questions  and  Answers  (Q&A), 

Troubleshooting  tips,  and  Common  equipment 
failure  symptom 

F.6.3.1 

Display  Historical  System 
Maintenance  Action 

Display  information  pertaining  historical 
system  maintenance  actions 

F.6.4 

Display  Logistics 

Information 

Display  information  related  to  Logistics  based 
on  system  hierarchy.  Data  include  Tech 

Manual  Bibliography,  Maintenance  Index  Page 
(MIP)/Preventive  Maintenance  (PMS)  listing, 
Allowance  Part  List  (APL),  Allowance 
Equipment  List  (AEL)  Listing,  On-Board 

Spares  list,  and  Links  to  download  Tech 

Manual. 

F.6.5 

Display  RMA  Analysis 

Data 

Display  information  related  to  Reliability, 
Maintainability,  and  Availability  of  each 
system  on  each  ship.  Data  include  System  Aq. 
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F.7.0 

Print  &  Save 

Print  and  Save  Data  performed  by 

Stakeholders. 

Table  17.  System  Functions 


hier  Provide  External... 


7 


F.1.0 

Provide  External 
Interface 


Function 


F.L1 


Execute  System 
Interface 


Function 


Project: 

Organiz... 

Date: 

Distance... 

NSWC  . . . 

Decemb... 

Figure  67.  Provide  External  Function  (F.1.0) 


hier  Obtain  Data 


j 


Project: 

Organization: 

Date: 

Distance  Support  Data  Aggre... 

NSWC  PHD 

December  2SF  2012 

Figure  68.  Obtain  Data  Functions  (F.2.0) 
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Figure  69.  Process  Data  Functions  (F.3.0) 


hier  Analyze  Data 


Project: 

Distance  Support  Data  Aggregation  System 

Organization: 

NSWC  PHD 

Date: 

December  26,  2012 

Figure  70.  Analyze  Data  Functions  (F.4.0) 


hier  Report  Data 


7 


Project: 

Organization: 

Date: 

Distance  Support  Data  Aggregation  System 

NSWC  PHD 

December  26,  2012 

Figure  71.  Report  Data  Functions  (F.5.0) 
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Figure  72.  Display  Data  Functions  (F.6.0) 


Network  Interface  Connection 


Internet  Access 


User  Enter  Data 
Ship  Data 

Fleet  Support  Infrastructure  Data  Base 


+  Fleet  3M  Data 
+  Fleet  Logistics  Data 
>  Fleet  Maintenance  Support  Data 
*  Fleet  RMA  Data 

Ships.,  Systems  and  POCs  Info 


() 

Operation  System 
Data  Aggregation  System 


Figure  73.  Provide  External  Interface  IDEFO  (F.1.0) 
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Ships.,  Systems  and  POCs  Info 


Fleet  Maintenance  Support  Data 


Fleet  RMA  Data 
Fleet  Logistics  Data 
Fleet  3M  Data 


MS  SQL  Server 


Data  Aggregation  System 


Figure  74.  Obtain  Data  IDEFO  (F.2.0) 
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Figure  75.  Process  Data  IDEFO  (F.3.0) 
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Figure  78.  Display  Data  IDEFO  (F.6.0) 
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R.l. 1.2.8 

Display  status  on  installed  engineering  alterations  and 
engineering  alterations  under  development  or  planned  for 
development 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.9 

Display  unclassified  CASREP  metrics 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.2. 10 

Display  known  problems  (issues  seen  by  other  Ships)  and 
frequently  asked  questions 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.11 

Display  lessons  learned  and  past  troubleshooting/problem 
resolution  information 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.2. 12 

Display  authorized  detailed  troubleshooting  procedures  for 
common  equipment  failures 

• 

• 

• 

• 

• 

R.l. 1.2. 13 

Display  CIM  information  (status) 

• 

• 

• 

• 

• 

• 

R.l. 1.2.14 

Display  a  ship's  combat  system  software  configuration 
(including  the  software  version  of  each  sub-system) 

• 

• 

• 

• 

• 

• 

R.l. 1.2. 15 

Display  INSURV  and  Availability  schedules  and  type  (SRA, 
DSRA,  RCOH,  etc.)  for  ships  and  provide  a  graphical 
representation  of  the  INSURV  and  Availability  schedules  of 
an  entire  Strike  Group 

• 

• 

• 

• 

• 

• 

R.l. 1.2.16 

Display  common  equipment  failures  and  corrective  action 
taken  per  element/system/subsystem/components 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.2.17 

Display  a  user-selectable  range  of  the  top  equipment  taking 
the  longest  time  to  repair 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.2. 18 

Display  a  user-selectable  range  of  the  top  LRUs  with  the 
highest  failure  rates  for  equipment  in  a  Pareto  diagram  for 
specific  systems 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.2. 19 

Display  (using  a  Pareto  diagram)  a  user-selectable  range  of 
the  top  high-usage  rate  LRUs  for  specific  systems 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.20 

Display  manning  level  perwork  center  pership 

• 

• 

• 

• 

• 
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R.l.  1.2.21 

Display  manning  qualification  to  conduct  mission  per  work 
center  pership  per  mission 

• 

• 

• 

• 

• 

• 

R.l.  1.2.22 

Display  performance  trends  per  ele me nt/syste m/subsystem 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.23 

Display  maintenance  work  hours  at  the 
ship/system/cabinet/LRU  level 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.24 

Display  past  and  current  technical  assistance  efforts 
requested  by  the  Fleet 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.25 

Correlate  PMS  history  with  material  readiness  or  equipment 
failures  and  display  the  results 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.26 

Display  the  composition  (unclassified)  and  planned 
deployment  dates  (Classified)  for  current  and  future  Strike 
Groups  and  other  deployers  identified  by  Fleet  Commanders 

• 

• 

• 

• 

• 

R.l.  1.2.27 

Display  CS  Safety  Issues  per  Ship  and  historical/trends  data 

• 

• 

• 

• 

• 

R.l.  1.2.28 

Display  current  configuration  and  past  configurations  up  to  5 
years  by  ship  by  system 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.2.29 

Display  an  average  time-open  bar  chart  for  2-Kilos 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.30 

Display  Mean  Time  To  Repair  (MTTR)  metrics  using  data  from 
2-Kilo  Maintenance  Man  Hours  (MMH)  and  repair  time 
information 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.31 

Display  Mean  Time  To  Repair  (MTTR)  Data  from  MRDB 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.2.32 

Display  Mean  Time  Between  Equipment  Mission  Critical 
Events  (MTB(EMCE))  and  Mean  Time  Between  Equipment 
Malfunction  Events  (MTB(EME))  or  obtain  and  display  data 
from  MRDB 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.3 

Logistics  Data 

R.l. 1.3.1 

Display  Allowance  Part  List  (APL)  of  all  systems 

• 

• 

• 

• 

• 

• 

R.l. 1.3.2 

Display  a  user-selectable  range  of  the  normalized  top 

Lowest  Replaceable  Unit  (LRU)  with  the  highest  cost  by 
system-year  or  cabinet-year 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 
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R.l. 1.3.3 

Provide  high  demand  and  high  cost  parts  per 
element/system/subsystem/LRU 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.3.4 

Provide  ship  class  and  ship  baseline  Cost  Report 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.3.5 

Provide  Cost  Reports  based  on  system/subsystem 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.3.6 

Compare  and  display  Mean  Logistics  Delay  Time  (MLDT)  for 
any  LRU  at  ship/system  level 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.3.7 

Display  parts  that  have  failed  in  the  past  quarter  above  a 
specified  threshold  in  three  categories 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.3.8 

Display  technical  publications  (bulletins)  developed  by 
shore  support  activities,  such  as  ISEA  and  RMC 

• 

• 

• 

• 

• 

• 

R.l.  1.3.9 

Display  the  number  of  failures  of  LRUs  at  the  ship  baselines, 
and  class  levels 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.3.10 

Display  supply  inventory,  sparing  info,  for  any  user-specified 
part  by  NIIN 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.3.11 

Display  DMS  data  by  system/equipment/IRU 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.3.12 

Display  part  numbers  and  part's  usage  based  on  historical 
data 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.4 

Training  Data 

R.l.  1.4.1 

Display  Training  Discrepancies  from  Ship  Reports,  Tech  Assist 
Visit  Report,  On-Site  Training  Report,  trip  report,  Availability 
report 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l.  1.4.2 

Display  training  deficiencies  from  Casualty  Reports 
(CASREP),  2-kilo  reports 

• 

• 

• 

• 

• 

• 

R.l.  1.5 

RMA  Analysis  Data 

R.l. 1.5.1 

Display  reliability,  maintainability,  and  availability  drivers 
from  individual  ship,  ship  baseline,  Strike  Group  and 
Warfare-Area  levels 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.5.2 

Display  an  assessment  of  system/subsystem  performance 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 1.5.3 

Display  Operational  Availability  (Ao),  Mean  Time  Between 
Failure  (MTBF),  &  Mean  Down  Time  (MDT)  data  per  ship 
baseline 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 
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R.l.  1.5.4 

Display  unclassified  and  clssified  Maintenance  Figure  of 

Merit  (MFOM)  indicators 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R. 1.1.6 

Reports 

• 

• 

• 

• 

• 

• 

• 

• 

• 

R.l. 2 

Physical  Charateristics 

R. 1.2.1 

Human  System  Integration 

R.1.3 

Reliability 

R.1.4 

Maintainability 

R.1.5 

Environment  Condition 

R.2.0 

Design  and  Construction 

R.2.1 

Data  Collection 

R.2.2 

Accessible  by  authorized  NMCI  Users 

R.2.3 

Data  Reporting 

R.2.4 

NMCI  Compliance 

R.3.0 

Component  Level  Requirements 

R.3.1 

Hardware 

R.3.2 

Software 

Figure  79.  Mapping  Requirements  to  System  Functions 
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NAME 

DEFINITION 

INPUT TO 

OUTPUT TO 

TRIGGERS 

#  of  CASREP  per  Ship  per  Year 

Data  relative  to  number  of 
CASREP  generated  per 
ship  peryear 

Function  F. 5.0  Report  Data 
Function  F. 5.3  Generate  System 
Status  Report  Function  F.5.4 
Generate  System  RMA  Report 
Function  F. 6.0  Display  Data 
Function  F.6.2  Display  Historical 
Fleet  Data 

Function  F. 4.0  Analyze  Data  Function 

F. 4.2  Conduct  System  Performance 
Trending  Analysis 

#  of  Issues  per  System  per  Year 

Data  relative  to  number  of 

equipment  issues 
(anomalies)  per  system 
peryear 

Function  F. 5.0  Report  Data 
Function  F. 5.3  Generate  System 
Status  Report  Function  F.5.4 
Generate  System  RMA  Report 
Function  F. 6.0  Display  Data 
Function  F.6.2  Display  Historical 
Fleet  Data 

Function  F.4.0Analyze  Data  Function 

F. 4.2  Conduct  System  Performance 
Trending  Analysis 

Access  Data 

Data  requested  by 
stakeholders 

Function  Ext.Func.3.0  Access  Data 

As  Needed 

Control  line.  Action  is 

executed  as  needed  only 

Function  Ext.Func.3.0  Access  Data 

Automatic 

Control  line.  Action  is 

executed  automatically 

Function  F.O  Provide  Data  Aggregation 

Capability  Function  F. 2.0 Obtain  Data  Function 

F. 2.3  Obtain  Data  from  Fleet  Support 
Infrastructure  Function  F. 2.3.1  Collect  Fleet 

Maintenance  Data  Function  F. 2.3.2  Collect  Fleet 

Logistics  Data  Function  F. 2.3. 2.1  Import 
Parts/Supplies  Data  Function  F. 2.3.3  Collect 
FleetTraining  Discrepancy  Data  Function  F. 2.3.4 
Collect  Fleet  RMA  Data  Function  F.3.0  Process 

Data  Function  F.3.1  Process  General  Information 
Function  F. 3.1.1  Provide  SME  POC  info  by 
Organization/System  Function  F. 3.1.2  Provide 
system  info  based  on  hierarchy  structure 

Function  F. 3.1.3  Provide  Frequent  Ask  Question 
Data  Function  F. 3.1.4  Provide  Blog  and  Forum 

Data  Function  F.3.2  Process  Maintenance  Data 

Function  F.3.3  Process  Logistics  Data  Function 
F.3.4  Process  Training  Data  Function  F. 3.4.1 
Process  Training  Discrepancy  Data  Function  F.3.5 
Process  RMA  Data  Function  F. 4.0  Analyze  Data 
Function  F. 4.1  Analyze  Maintenance  Data 
Function  F. 4.2  Conduct  System  Performance 
Trending  Analysis  Function  F. 4.3  Compute 

System  Ao/Ai  based  on  RMA  data  Function  F.4.4 
Conduct  Cost  Analysis  Function  F.5.0  Report 

Data  Function  F. 5.1  Generate  System 

Assessment  Report  Function  F.5.2  Generate 
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Blog  and  Forum  Data 

Data  is  extracted  from 

Blog  and  Forum  shared  by 
ship  personnel  and  fleet 
support  agents 

Function  F. 6.0  Display  Data 
Function  F. 6.1  Display  Fleet 
Support  Information  Function 

F. 6.1.1  Display  FAQ,  Blog  and 
Forum  data 

Function  F.3.0  Process  Data  Function 

F.3.1  Process  General  Information 
Function  F.3. 1.4  Provide  Blog  and  Forum 

Data 

By  Request 

Control  line.  Action  is 

executed  by  request 

- -  - - - - - - - 

Function  Ext. Func.2.0  Collect  and  Disseminate 

Fleet  Data  Function  Ext. Func.3.0  Access  Data 
Function  F.O  Provide  Data  Aggregation 

Capability  Function  F. 2.0 Obtain  Data  Function 
F.2.2  Obtain  Data  from  Fleet  Function  F. 2.2.1 
Import  Data  from  Remote  Assessment  Report 
Function  F. 2.2.4  Import  Fleet  Data  from  On-Site 
Assessment  Function  F. 2. 3  Obtain  Data  from 
Fleet  Support  Infrastructure  Function  F. 2.3.1 
Collect  Fleet  Maintenance  Data  Function  F.2.3.2 
Collect  Fleet  Logistics  Data  Function  F.2.3.2.1 
Import  Parts/Supplies  Data  Function  F. 2.3.3 
Collect  Fleet  Training  Discrepancy  Data  Function 

F. 2.3.4 Collect  Fleet  RMA  Data  Function  F.3.0 

Process  Data  Function  F.3.1  Process  General 

Information  Function  F. 3.1.1  Provide  SME  POC 
info  by  Organization/System  Function  F. 3.1.2 
Provide  system  info  based  on  hierarchy 
structure  Function  F. 3.1.3  Provide  Frequent  Ask 
Question  Data  Function  F. 3.1.4  Provide  Blog  and 

Forum  Data  Function  F.3.2  Process  Maintenance 

Data  Function  F.3.3  Process  Logistics  Data 
Function  F.3.4  Process  Training  Data  Function 

F. 3.4.1  Process  Training  Discrepancy  Data 

Function  F.3.5  Process  RMA  Data  Function  F.4.1 

Analyze  Maintenance  Data  Function  F.4.2 
Conduct  System  Performance  Trending  Analysis 

CASREP  Metrics 

Metrics  relative  to  CASREP 

Function  F. 5.0  Report  Data 
Function  F.5.1  Generate  System 
Assessment  Report  Function 

F.5.3  Generate  System  Status 
Report  Function  F. 5.4  Generate 
System  RMA  Report  Function 

F. 6.0  Display  Data  Function  F.6.2 
Display  Historical  Fleet  Data 

Function  F. 4.0  Analyze  Data  Function 

F. 4.2  Conduct  System  Performance 
Trending  Analysis 
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Common  Equipment  Failures 

Data  relative  to  common 
equipmentfailures 

Function  F. 5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function 

F. 5.2  Generate  Logistics  Report 
Function  F. 5.3  Generate  System 
Status  Report  Function  F.5.4 
Generate  System  RMA  Report 
Function  F. 6.0  Display  Data 
Function  F. 6.3  Display  Corrective 
Maintenance  Information 

Function  F. 6.3.1  Display  Historical 
System  Maintenance  Action 

Function  F. 4.0  Analyze  Data  Function 

F. 4.2  Conduct  System  Performance 
Trending  Analysis 

Cost  of  Parts  Replacement  per 
system/ship/year 

Data  relative  to  part 
replacement  cost 
expenditures  pership  per 

year 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F. 5.3  Generate 
System  Status  Report  Function 

F. 6.0  Display  Data  Function  F.6.4 
Display  Logistics  Information 

Function  F.4.0Analyze  Data  Function 
F.4.4  Conduct  Cost  Analysis 

Cost  Saving  by  using  Distance 

Support 

Saving  cost  by  using  DS 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F. 5.3  Generate 
System  Status  Report  Function 

F. 6.0  Display  Data  Function  F.6.2 
Display  Historical  Fleet  Data 

Function  F. 4.0  Analyze  Data  Function 
F.4.4  Conduct  Cost  Analysis 

DMS  Data 

Data  relative  to  DMS 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F. 6.0  Display 

Data  Function  F.6.4  Display 
Logistics  Information 

Function  F. 4.0  Analyze  Data  Function 

F. 4.2  Conduct  System  Performance 
Trending  Analysis 

FAQ  Data 

Technical  interchange 
data  between  ship 
personnel  and  fleet 
support  agents 

Function  F. 6.0  Display  Data 
Function  F. 6.1  Display  Fleet 
Support  Information  Function 

F. 6.1.1  Display  FAQ,  Blog  and 

Forum  data 

Function  F.3.0  Process  Data  Function 

F.3.1  Process  General  Information 
Function  F. 3.1.3  Provide  Frequent  Ask 
Question  Data 
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Fleet  3M  Data 

Fleet  3M  data  provided  by 
NSLC 

Function  F. 2.0  Obtain  Data 

Function  F. 2.3  Obtain  Data  from 

Fleet  Support  Infrastructure 
Function  F. 2.3.1  Collect  Fleet 

Maintenance  Data  Function 

F. 2.3.2  Collect  Fleet  Logistics  Data 
Function  F. 2.3. 2.1  Import 
Parts/Supplies  Data  Function 

F. 2.3.3  Collect  Fleet  Training 
Discrepancy  Data 

Function  F.1.0  Provide  External 

Interface  Function  F.1.1  Execute  System 
Interface 

Fleet  Logistics  Data 

Logistics  data  provided  by 
NSLC/  NAVSUP 

Function  F. 2.0  Obtain  Data 

Function  F. 2.3  Obtain  Data  from 

Fleet  Support  Infrastructure 
Function  F. 2.3. 2  Collect  Fleet 

Logistics  Data  Function  F. 2. 3.2.1 
Import  Parts/Supplies  Data 
Function  F. 2.3. 2.2  Import  Parts 
Inventory  Data 

Function  F.1.0  Provide  External 

Interface  Function  F.1.1  Execute  System 
Interface 

Fleet  Maintenance  Support  Data 

Data  relative  to  fleet 

maintenance  actions 

Function  F. 2.0  Obtain  Data 

Function  F. 2.2  Obtain  Data  from 
Fleet  Function  F. 2. 2.1  Import 

Data  from  Remote  Assessment 
Report  Function  F. 2.2.2  Extract 
Data  from  Ship's  Data  Recording 
Function  F. 2.2. 3  Import  Fleet 

Tech  Assist  Data  Function  F. 2.2.4 

Import  Fleet  Data  from  On-Site 

Assessment 

Function  F.1.0  Provide  External 

Interface  Function  F.1.1  Execute  System 
Interface 

Fleet  RMA  Data 

Fleet  historical  data 

relative  to  RMA 

Function  F. 2.0  Obtain  Data 

Function  F. 2.3  Obtain  Data  from 

Fleet  Support  Infrastructure 
Function  F. 2.3.4 Collect  Fleet 

RMA  Data 

Function  F.1.0  Provide  External 

Interface  Function  F.1.1  Execute  System 
Interface 

Fleet  Support  Infrastructure  Data 

Base 

Data  provided  by  fleet 
support  infrastructure 

data  base 

Function  F.O  Provide  Data 
Aggregation  Capability  Function 
F.1.0  Provide  External  Interface 
Function  F. 1.1  Execute  System 

Interface 

Function  Ext. Func.2.0  Collect  and 

Disseminate  Fleet  Data 
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Formatted  Fleet  Maintenance 

Support  Data 

Maintenance  Data 

provided  by  SME 

Function  F. 3.0  Process  Data 

Function  F. 3.2  Process 

Maintenance  Data  Function  F.3.3 

Process  Logistics  Data  Function 
F.3.4  Process  Training  Data 
Function  F. 3.4.1  Process  Training 
Discrepancy  Data  Function  F.3.5 

Process  RMA  Data 

Function  F. 2.0  Obtain  Data  Function 

F.2.2  Obtain  Data  from  Fleet  Function 

F. 2.2.1  Import  Data  from  Remote 
Assessment  Report  Function  F. 2.2.2 
Extract  Data  from  Ship's  Data  Recording 
Function  F. 2.2.3  Import  Fleet  Tech  Assist 
Data  Function  F. 2.2.4  Import  Fleet  Data 

from  On-Site  Assessment 

Formatted  Fleet  System 

Maintenance  Data 

Maintenance  Data  from 

Fleet 

Function  F.3.0  Process  Data 

Function  F. 3. 2  Process 

Maintenance  Data  Function  F.3.3 

Process  Logistics  Data  Function 
F.3.4  Process  Training  Data 
Function  F. 3.4.1  Process  Training 
Discrepancy  Data  Function  F.3.5 

Process  RMA  Data 

Function  F. 2.0  Obtain  Data  Function 

F. 2.3  Obtain  Data  from  Fleet  Support 
Infrastructure  Function  F. 2.3.1  Collect 

Fleet  Maintenance  Data  Function  F. 2.3.3 
Collect  Fleet  Training  Discrepancy  Data 

Formatted  General  System 
Information  Data 

Formatted  general 
information  relative  to 
SMEs,  ship  information, 
system  information 

Function  F.3.0  Process  Data 

Function  F. 3.1  Process  General 

Information  Function  F. 3.1.2 

Provide  system  info  based  on 
hierarchy  structure  Function 

F. 3.1.3  Provide  Frequent  Ask 
Question  Data  Function  F. 3.1.4 
Provide  Blog  and  Forum  Data 
Function  F.3.3  Process  Logistics 

Data  Function  F.3.5  Process  RMA 

Data 

Function  F. 2.0  Obtain  Data  Function 

F. 2.1  Obtain  Data  from  User  Inputs 
Function  F. 2.1.1  Receive  Data  via  Web 
Form  Function  F. 2.1.2  Import  and 

Format  Data  Entered  by  User 

Formatted  Logistics  Data 

Formatted  data  relative  to 
logistics  supply  support, 
inventory 

Function  F.3.0  Process  Data 

Function  F.3.3  Process  Logistics 

Data  Function  F.3.5  Process  RMA 

Data 

Function  F. 2.0  Obtain  Data  Function 

F.2.3  Obtain  Data  from  Fleet  Support 
Infrastructure  Function  F. 2.3.2  Collect 
Fleet  Logistics  Data  Function  F.2.3.2.1 
Import  Parts/Supplies  Data  Function 

F.2.3. 2. 2  Import  Parts  Inventory  Data 

Formatted  SME  POC  List 

Formatted  data  relative  to 

SME  POC  Information 

Function  F.3.0  Process  Data 

Function  F. 3.1  Process  General 

Information  Function  F.3.1.1 
Provide  SME  POC  info  by 
Organization/System 

Function  F. 2.0  Obtain  Data  Function 

F. 2.1  Obtain  Data  from  User  Inputs 
Function  F. 2.1.1  Receive  Data  via  Web 
Form  Function  F. 2.1.2  Import  and 

Format  Data  Entered  by  User 
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Formatted  System  Reliability  Data 

Formatted  data  relative  to 
ship  system  RMA 
information 

Function  F. 3.0  Process  Data 

Function  F.3.5  Process  RMA  Data 

Function  F. 2.0  Obtain  Data  Function 

F. 2. 3  Obtain  Data  from  Fleet  Support 
Infrastructure  Function  F. 2. 3.4 Collect 

Fleet  RMA  Data 

Highest  LRU  Failures 

Information  regarding  LRU 
that  has  the  highest 

failure  rate 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F. 5.3  Generate 
System  Status  Report  Function 
F.5.4  Generate  System  RMA 

Report  Function  F. 6.0  Display 

Data  Function  F. 6.2  Display 

Historical  Fleet  Data 

Function  F. 4.0  Analyze  Data  Function 

F. 4.2  Conduct  System  Performance 
Trending  Analysis 

Historical  Maintenance  Data 

Historical  fleet 

maintenance  data 

Function  Ext. Func.4.0  Display 
Aggregation  Data  Function  F.7.0 

Print  &  Save  Data 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function  F.5.3 
Generate  System  Status  Report  Function 
F.5.4  Generate  System  RMA  Report 
Function  F.6.0  Display  Data  Function 

F.6.2  Display  Historical  Fleet  Data 
Function  F. 6.3  Display  Corrective 
Maintenance  Information  Function 

F. 6.3.1  Display  Historical  System 

Maintenance  Action 

Historical  System  Performance 
Trends  Data 

Historical  data  relative  to 
system  performance 
trends 

Function  Ext. Func.4.0  Display 
Aggregation  Data  Function  F.7.0 

Print  &  Save  Data 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function  F.5.3 
Generate  System  Status  Report  Function 
F.5.4  Generate  System  RMA  Report 
Function  F.6.0  Display  Data  Function 

F.6.2  Display  Historical  Fleet  Data 
Function  F. 6.5  Display  RMA  Analysis 

Data 

Internet  Access 

Control  line.  Action  is 

executed  when  internet 

access  becomes  available 

Function  F. 1.0  Provide  External  Interface 

Function  F.1.1  Execute  System  Interface 

Function  F.3. 1.4  Provide  Blog  and  Forum  Data 
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Known  Equipment  Problem 

Data  relative  to  known 

equipment 

problem/failure 

Function  F. 5.0  Report  Data 
Function  F. 5.3  Generate  System 
Status  Report  Function  F.5.4 
Generate  System  RMA  Report 
Function  F. 6.0  Display  Data 
Function  F. 6.3  Display  Corrective 
Maintenance  Information 

Function  F. 6.3.1  Display  Historical 
System  Maintenance  Action 

Function  F.4.0Analyze  Data  Function 
F.4.1Analyze  Maintenance  Data 

List  of  SME  POC  by  System  by 
Organization 

Data  relative  to  SME  POC 
information  listed  by 
organization 

Function  F. 6.0  Display  Data 
Function  F. 6.1  Display  Fleet 
Support  Information  Function 

F. 6.1.2  Display  SME  POC  Info 

Function  F.3.0  Process  Data  Function 

F. 3.1  Process  General  Information 

Function  F. 3.1.1  Provide  SME  POC  info 
by  Organization/System 

Logistics  Cost  Data 

Data  relative  to  logistics 
supply  cost 

Function  F.6.0  Display  Data  Function 

F.6.2  Display  Historical  Fleet  Data 
Function  F. 6.4  Display  Logistics 
Information 

Logistics  Data 

Data  relative  to  Logistics 
supply,  parts  usage,  cost, 
expenditures,  etc... 

Function  F.6.0  Display  Data  Function 

F.6.2  Display  Historical  Fleet  Data 
Function  F. 6.4  Display  Logistics 
Information 

Logistics  Reports 

Reports  contain  logistics 
information  such  as  parts 
usage,  part  cost,  ship 
expenditures,  LRU  highest 
cost/expenditure,  etc... 

Function  Ext. Func. 4.0 Display 
Aggregation  Data  Function  F.7.0 

Print  &  Save  Data 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.5.0  Report  Data 
Function  F.5.2  Generate  Logistics  Report 

Maintenance  Cost  Data 

Cost  data  relative  to  ship's 
equipment  maintenance 

Function  F.5.3  Generate  System  Status 
Report  Function  F.6.0  Display  Data 
Function  F.6.2  Display  Historical  Fleet 
Data  Function  F. 6.4  Display  Logistics 
Information 

Manning  Level  per  Work  Center  per 
Ship 

Data  relative  to  manning 
level  pership  perbaseline 

Function  F. 5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function 

F.5.2  Generate  Logistics  Report 
Function  F. 5.3  Generate  System 
Status  Report  Function  F.5.4 
Generate  System  RMA  Report 
Function  F. 6.0  Display  Data 
Function  F. 6.5  Display  RMA 
Analysis  Data 

Function  F.4.0Analyze  Data  Function 
F.4.3  Compute  System  Ao/Ai  based  on 
RMA  data 
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Manual 

Control  line.  Action  is 

executed  manually 

Function  F.O  Provide  Data  Aggregation 

Capability  Function  F. 2.0  Obtain  Data  Function 
F.2.1  Obtain  Data  from  User  Inputs  Function 
F.2.1.1  Receive  Data  via  Web  Form  Function 

F.2.2  Obtain  Data  from  Fleet  Function  F. 2.2.1 
Import  Data  from  Remote  Assessment  Report 
Function  F.2.2. 2  Extract  Data  from  Ship's  Data 
Recording  Function  F. 2.2.3  Import  Fleet  Tech 
Assist  Data  Function  F. 2.2.4  Import  Fleet  Data 
from  On-Site  Assessment  Function  F.2.3  Obtain 
Data  from  Fleet  Support  Infrastructure  Function 
F.2.3. 1  Collect  Fleet  Maintenance  Data  Function 
F.2.3. 2  Collect  Fleet  Logistics  Data  Function 

F.2.3. 2.1  Import  Parts/Supplies  Data  Function 
F.2.3. 3  Collect  FleetTraining  Discrepancy  Data 
Function  F.2.3.4Collect  Fleet  RMA  Data  Function 

F.3.0  Process  Data  Function  F.3.1  Process 

General  Information  Function  F. 3. 1.1  Provide 

SME  POC  info  by  Organization/System  Function 
F.3.1.2  Provide  system  info  based  on  hierarchy 
structure  Function  F. 3.1.3  Provide  Frequent  Ask 
Question  Data  Function  F.3.2  Process 

Maintenance  Data  Function  F.3.3  Process 

Logistics  Data  Function  F.3.4  Process  Training 

Data  Function  F.3.4.1  Process  Training 
Discrepancy  Data  Function  F.3.5  Process  RMA 
Data  Function  F.4.0  Analyze  Data  Function  F.4.1 

MTBF  per  System/Ship/Year 

Data  relative  to 
equipment/LRU  MTBF  per 
system  pership  peryear 

Function  F. 5.0  Report  Data 
Function  F. 5.4  Generate  System 
RMA  Report  Function  F.6.0 

Display  Data  Function  F.6.5 

Display  RMA  Analysis  Data 

Function  F. 4.0  Analyze  Data  Function 
F.4.3  Compute  System  Ao/Ai  based  on 
RMA  data 

MUR  per  System  per  year 

Data  relative  to  MUR  per 
system  peryear 

Function  F. 5.0  Report  Data 
Function  F. 5.4  Generate  System 
RMA  Report  Function  F.6.0 

Display  Data  Function  F.6.5 

Display  RMA  Analysis  Data 

Function  F.4.0Analyze  Data  Function 
F.4.3  Compute  System  Ao/Ai  based  on 
RMA  data 

Network  Interface  Connection 

Control  line.  Action  is 

executed  when  network 

interface  connection 

becomes  available 

Function  F.  1.0  Provide  External  Interface 

Function  F.1.1  Execute  System  Interface 
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Periodic 

Control  line.  Action  is 
executed  periodically 

Function  Ext. Func.1.0  Ship  Sends  Data  to  Shore 
Function  Ext. Func.2.0  Collect  and  Disseminate 

Fleet  Data  Function  F.O  Provide  Data 

Aggregation  Capability  Function  F. 2.0  Obtain 

Data  Function  F. 2.3  Obtain  Data  from  Fleet 
Support  Infrastructure  Function  F. 2.3.1  Collect 
Fleet  Maintenance  Data  Function  F. 2.3.2  Collect 
Fleet  Logistics  Data  Function  F.2.3.2.1  Import 
Parts/Supplies  Data  Function  F. 2.3.3  Collect 

Fleet  Training  Discrepancy  Data  Function  F. 2.3.4 
Collect  Fleet  RMA  Data  Function  F.3.0  Process 

Data  Function  F.3.5  Process  RMA  Data  Function 

F. 4.1  Analyze  Maintenance  Data  Function  F.4.2 
Conduct  System  Performance  Trending  Analysis 
Function  F.4.3  Compute  System  Ao/Ai  based  on 
RMA  data  Function  F.4.4  Conduct  Cost  Analysis 
Function  F. 6.0  Display  Data  Function  F.6.2 

Display  Historical  Fleet  Data  Function  F.6.4 
Display  Logistics  Information  Function  F.6.5 
Display  RMA  Analysis  Data 

Print  Reports 

Reports  generated  via 

Print 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.7.0  Print  &  Save 

Data 

Processed  Logistics  Data 

Logistics  data  have  already 
been  processed 

Function  F.4.0  Analyze  Data 
Function  F. 4.3  Compute  System 
Ao/Ai  based  on  RMA  data 

Function  F.4.4  Conduct  Cost 
Analysis 

Function  F.3.0  Process  Data  Function 

F.3.3  Process  Logistics  Data 

Processed  Maintenance  Data 

Ship  maintenance  data 
have  already  been 
processed 

Function  F.4.0  Analyze  Data 
Function  F.4.1Analyze 
Maintenance  Data  Function  F.4.2 

Conduct  System  Performance 
Trending  Analysis  Function  F.4.3 
Compute  System  Ao/Ai  based  on 
RMA  data  Function  F.4.4  Conduct 
Cost  Analysis 

Function  F.3.0  Process  Data  Function 

F.3.2  Process  Maintenance  Data 

Processed  Reliability  Data 

Ship  reliability  data  have 
already  been  processed 

Function  F.4.0  Analyze  Data 
Function  F.4.2  Conduct  System 
Performance  Trending  Analysis 
Function  F.4.3  Compute  System 
Ao/Ai  based  on  RMA  data 

Function  F.4.4  Conduct  Cost 
Analysis 

Function  F.3.0  Process  Data  Function 

F.3.5  Process  RMA  Data 
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Processed  Training  Data 

Ship  personnel  training 
data  have  already  been 
processed 

Function  F.4.0  Analyze  Data 
Function  F. 4.3  Compute  System 
Ao/Ai  based  on  RMA  data 

Function  F. 4.4  Conduct  Cost 
Analysis 

Function  F.3.0  Process  Data  Function 

F.3.4  Process  Training  Data  Function 

F. 3.4.1  Process  Training  Descrepancy 

Data 

Q&A  Data 

Data  captured  from  Q&A, 
forum  posted  by  ship 
personnel  and  fleet 
support  agents 

Function  Ext. Func.4.0  Display 
Aggregation  Data 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.6.0  Display  Data 
Function  F.6.1  Display  Fleet  Support 
Information  Function  F. 6.1.1  Display 

FAQ,  Blog  and  Forum  data  Function  F.6.3 
Display  Corrective  Maintenance 
Information  Function  F. 6.3.1  Display 
Historical  System  Maintenance  Action 

RMA  Data 

Data  relative  to  ship  RMA 

Function  F.6.0  Display  Data  Function 

F.6.2  Display  Historical  Fleet  Data 
Function  F. 6.5  Display  RMA  Analysis 

Data 

Safety  Issue  Related  to 

Maintenance 

Data  relative  to  safety 
isssue  while  performing 
equipment  maintenance 

Function  F. 5.0  Report  Data 
Function  F. 5.3  Generate  System 
Status  Report  Function  F.6.0 
Display  Data  Function  F.6.2 

Display  Historical  Fleet  Data 

Function  F.4.0  Analyze  Data  Function 

F. 4.1  Analyze  Maintenance  Data 

Ship  and  System  Info 

Data  relative  to  ship  and 
system  information 

Function  F.6.0  Display  Data 
Function  F. 6.1  Display  Fleet 
Support  Information  Function 

F. 6.1.3  Display  Ship  and  System 
Info 

Function  F.3.0  Process  Data  Function 

F.3.1  Process  General  Information 
Function  F. 3.1.2  Provide  system  info 
based  on  hieararchy  structure 

Ship  and  System  Information 

Ship  Name  System 
Nomenclature  and 
Configuration  (APL,  Part 
Number) 

Function  F.6.0  Display  Data  Function 

F.6.1  Display  Fleet  Support  Information 
Function  F. 6.1.3  Display  Ship  and  System 
Info  Function  F.6.4  Display  Logistics 
Information 

Ship  Data 

Ship  data  such  as 
homeport,  work  centers, 
POCs,  INMARSAT  phone 
numbers,  etc 

Function  Ext. Func.2.0  Collect  and 

Disseminate  Fleet  Data  Function 
F.O  Provide  Data  Aggregation 
Capability  Function  F. 1.0  Provide 
External  Interface  Function  F.1.1 

Execute  System  Interface 

Function  Ext. Fund. 0  Ship  Sends  Data  to 

Shore 
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Ship  force  Training  Discrepancies 
per  Ship 

Data  relative  to  ship  force 
training  discrepancies 
reported  from  tech  assist, 
system  assessment,  and 
INSURVs,  etc... 

Function  F. 5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function 

F.5.3  Generate  System  Status 
Report  Function  F. 5.4  Generate 
System  RMA  Report  Function 

F. 6.0  Display  Data  Function  F.6.5 
Display  RMA  Analysis  Data 

Function  F.4.0Analyze  Data  Function 
F.4.3  Compute  System  Ao/Ai  based  on 
RMA  data 

Ships,  Systems  and  POCs  Info 

Data  relative  to  ship, 
system ,  ship  personnel 
POCs  information 

Function  F. 2.0  Obtain  Data 

Function  F. 2.1  Obtain  Data  from 

User  Inputs  Function  F. 2.1.1 

Receive  Data  via  Web  Form 
Function  F. 2.1.2  Import  and 
Format  Data  Entered  by  User 

Function  F. 1.0  Provide  External 

Interface  Function  F.1.1  Execute  System 
Interface 

SME  POCs  Information 

Data  relative  to  SME  POCs 

information 

Function  F.6.0  Display  Data  Function 

F.6.1  Display  Fleet  Support  Information 
Function  F. 6.1.2  Display  SME  POC  Info 

Supported  Data 

Data  relative  to  fleet 
support  information 

Function  Ext.Func.3.0  Access  Data 

Function  Ext. Func.4.0  Display 
Aggregation  Data 

System  Assessment  Reports 

Reports  generated  from 
system  assessment 
conducted  by  fleet 
support  agents 

Function  Ext. Func.4.0  Display 
Aggregation  Data  Function  F.7.0 

Print  &  Save  Data 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.5.0  Report  Data 
Function  F.5.1  Generate  System 
Assessment  Report  Function  F.5.3 
Generate  System  Status  Report  Function 
F.5.4  Generate  System  RMA  Report 

System  Availability  to  Support 
Warfare  Area 

Data  relative  to  system 
performance  status  that 
are  required  to  support 
ship's  mission 

Function  F. 5.0  Report  Data 
Function  F.5.1  Generate  System 
Assessment  Report  Function 

F.5.3  Generate  System  Status 
Report  Function  F. 5. 4  Generate 
System  RMA  Report  Function 

F. 6.0  Display  Data  Function  F.6.5 
Display  RMA  Analysis  Data 

Function  F.4.0Analyze  Data  Function 
F.4.3  Compute  System  Ao/Ai  based  on 
RMA  data 

System  Configuration  Data  (APL, 

AEL,  AAP, ...) 

Data  relative  to  system 
configuration  such  as  APL, 
AEL,  AAP,  COSAL,  COSBAL, 

etc... 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F. 6.0  Display 

Data  Function  F. 6.1  Display  Fleet 
Support  Information  Function 

F. 6.1.3  Display  Ship  and  System 
Info 

Function  F.4.0Analyze  Data  Function 

F. 4.1  Analyze  Maintenance  Data 
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System  Mean  Down  Time  (MDT) 

Data  relative  to  ship 
system  MDT 

Function  F. 5.0  Report  Data 
Function  F. 5.3  Generate  System 
Status  Report  Function  F.5.4 
Generate  System  RMA  Report 
Function  F. 6.0  Display  Data 
Function  F. 6.5  Display  RMA 
Analysis  Data 

Function  F.4.0Analyze  Data  Function 
F.4.3  Compute  System  Ao/Ai  based  on 
RMA  data 

System  Performance  Trends  by  Ship 

Data  relative  to  historical 
system  performance 
trends  by  ship  by  baseline 

Function  F. 5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function 

F.5.3  Generate  System  Status 
Report  Function  F.5.4  Generate 
System  RMA  Report  Function 

F. 6.0  Display  Data  Function  F.6.5 
Display  RMA  Analysis  Data 

Function  F.4.0Analyze  Data  Function 
F.4.2  Conduct  System  Performance 
Trending  Analysis 

System  Performance  Trends  Data 

Data  relative  to  system 
performance  trends 

Function  F.6.0  Display  Data  Function 

F.6.2  Display  Historical  Fleet  Data 

Function  F.6.5  Display  RMA  Analysis 

Data 

System  Status  Reports 

Reports  relative  to  ship 
system  status 

Function  Ext. Func.4.0  Display 
Aggregation  Data 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function  F.5.3 
Generate  System  Status  Report  Function 
F.5.4  Generate  System  RMA  Report 

System  RMA  Reports 

Reports  relative  to  ship 
system  RMA 

Function  Ext. Func.4.0  Display 
Aggregation  Data  Function  F.7.0 

Print  &  Save  Data 

Function  F.O  Provide  Data  Aggregation 
Capability  Function  F.5.0  Report  Data 
Function  F.5.4  Generate  System  RMA 
Report 

Tech  Assist  Cost  per 
System/Ship/Year 

Data  relative  to  cost  spent 
for  tech  assist  per  system 
per  ship  peryear 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F.5.4  Generate 
System  RMA  Report  Function 

F. 6.0  Display  Data  Function  F.6.2 
Display  Historical  Fleet  Data 

Function  F.4.0Analyze  Data  Function 
F.4.4  Conduct  Cost  Analysis 

Tech  Assist  Metrics 

Data  relative  to  tech  assist 
metrics  conducted  by 
fleet  support  agents 

Function  F. 5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function 

F.5.3  Generate  System  Status 
Report  Function  F.5.4  Generate 
System  RMA  Report  Function 

F. 6.0  Display  Data  Function  F.6.2 
Display  Historical  Fleet  Data 

Function  F.4.0Analyze  Data  Function 

F. 4.1  Analyze  Maintenance  Data 
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Top  Equipment  Take  Longest  Time 

To  Repair 

Data  relative  to  a  system 
orequipmentthat  has  the 
highest  MTTR 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F. 5.3  Generate 
System  Status  Report  Function 

F. 5.4  Generate  System  RMA 

Report  Function  F. 6.0  Display 

Data  Function  F. 6.5  Display  RMA 
Analysis  Data 

Function  F. 4.0  Analyze  Data  Function 

F. 4.2  Conduct  System  Performance 
Trending  Analysis 

Top  Replaced  LRU  with  the  highest 
Cost  per  System  for  last  5  years 

Data  relative  to  a  LRU  that 
has  the  highest  cost  per 
system  for  last  5  year 

Function  F. 5.0  Report  Data 
Function  F. 5.2  Generate  Logistics 
Report  Function  F. 5.3  Generate 
System  Status  Report  Function 

F. 5.4  Generate  System  RMA 

Report  Function  F. 6.0  Display 

Data  Function  F. 6.4  Display 
Logistics  Information 

Function  F.4.0Analyze  Data  Function 
F.4.4  Conduct  Cost  Analysis 

Training  Data 

Data  relative  to  ship 
personnel  training 

Function  F.6.0  Display  Data  Function 

F.6.2  Display  Historical  Fleet  Data 
Function  F. 6.5  Display  RMA  Analysis 

Data 

Troubleshooting  Lesson  Learned 

Data  relative  to 
equipment 

troubleshooting  lesson 
learned 

Function  F. 5.0  Report  Data 
Function  F. 5.1  Generate  System 
Assessment  Report  Function 

F. 6.0  Display  Data  Function  F.6.3 
Display  Corrective  Maintenance 
Information  Function  F. 6.3.1 

Display  Historical  System 
Maintenance  Action 

Function  F. 4.0  Analyze  Data  Function 

F. 4.1  Analyze  Maintenance  Data 

User  Enter  Data 

Data  is  entered  by  the 

user 

Function  F.O  Provide  Data 

Aggregation  Capability  Function 

F. 1.0  Provide  External  Interface 

Function  F.  1.1  Execute  System 
Interface 

Function  Ext.Func.3.0  Access  Data 

Table  18.  System  Function  Data  Exchanges 
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APPENDIX  C.  RISK  ANALYSIS  THROUGH  COSYSMO 


Figures  80,  81,  82,  83,  and  84  diagram  the  results  from  the  Cost  Analysis 
performed  by  this  group.  Using  COSYSMO  software,  the  team  conducted  a  Cost 
Analysis  of  what  it  would  cost  to  create  a  new  system  and  what  it  would  cost  to  modify 
the  current  ESDS  system. 
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NEW  DS  SYSTEM 

ESDS  + 

NOTE:  Inputs  have  RED  Text.  All 
other  values  are  calculated. 

NEW  REQUIREMENT? 

NEW  EASY 

NEW  NOMINAL 

NEW  DIFFICULT 

Algorithms  (New) 

I 

REUSE  EASY 

1 

REUSE  DIFFICULT 

NEW  EASY 

I 

NEW  DIFFICULT 

Algorithms  (New) 

Requirements 

Definition 

Complexity 

I 

1 

I 

I 

1 

i 

R.1.1.1 

External  Interface 

This  system  shall  be  capable  of  interface 
with  other  systems  including  human 
interface  and  data  base  to  collect  and 
provide  necessary  data  to  perform  all  the 
functions. 

DIFFICULT 

1 

1 

1 

1 

R. 1.1.2 

Fleet  Maintenance  Support  Data 
and  Metrics 

Group  Title 

R.1.1.2.1 

Display  a  list  of  system/subsystem 
on  each  platform 

The  system  shall  provide  a  list  of 
system/subsystem  on  each  platform. 

EASY 

1 

1 

1 

1 

R. 1.1. 2.2 

Display  SME  contact  information 
for  each  system/subsystem 

The  system  shall  display  SME  contact 
information  for  each  system/subsystem 

EASY 

1 

1 

1 

1 

R.1.1.2.3 

Display  a  list  of  Open  CASREP, 
Trouble  Tickets,  and  Help  Desk 
items  open  for  a  speciific  ship  or 
an  entire  Strike  Group 

The  system  shall  display  a  list  of  Open 
CASREP,  Trouble  Tickets,  and  Help  Desk 
items  open  for  a  speciific  ship  or  an 
entire  Strike  Group 

NOMINAL 

1 

1 

1 

1 

R.1.1.2.3. 

Search  and  Display  CASREP  data 
based  on  category,  ship,  element, 
system  subsystem,  sympton,  status 

The  system  shall  be  able  to  search  and 
display  the  CASREP  data  based  on 
category,  ship,  element,  system 
subsystem,  sympton,  and  status 

NOMINAL 

1 

1 

0 

1 

R.1.1.2.4 

Display  Area  of  Responsibility 
(AOR)  requirements/standing 
Orders  (Classified)  for  all  platform 
in  a  Strike  Group 

The  system  shall  display  Area  of 
Responsibility  (AOR) 
requirements/Standing  Orders 
(Classified)  for  all  platform  in  a  Strike 
Group 

NOMINAL 

1 

1 

1 

1 

R.1.1.2.5 

Display  outstanding/open  CASREP, 

2  Kilo,  Tech  Assist  Visit  Request 

The  system  shall  display 
outstanding/open  CASREP,  2  Kilo,  Tech 
Assist  Visit  Request 

NOMINAL 

1 

1 

1 

1 

R.1.1.2.6 

Display  Technical  Assist  Visit 
Reports  (TAVRs)  by  system 

The  system  shall  display  Technical  Assist 
Visit  Reports  (TAVRs)  by  system 

EASY 

1 

1 

1 

1 

R.1.1.2.7 

Display  the  past  and  current  ISEA 
investigations  at  the  systems, 
equipment,  and  LRU  levels 

The  system  shall  display  the  past  and 
current  ISEA  investigations  at  the 
systems,  equipment,  and  LRU  levels 

NOMINAL 

1 

1 

1 

1 

Display  status  on  installed 
engineering  alterations  and 
engineering  alterations  under 

The  system  shall  display  status  on 
installed  engineering  alterations  and 

anninaarinn  alfarafinnr  unrlar 

EASY 

1 

1 

1 

1 

Figure  80.  Function  Count  and  Complexity  Analysis 
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NOTE:  Inputs 
have  RED  Text 

NEW  SYSTEM 

E5D5  + 

EASY 

NOMINAL 

DIFFICULT 

New  Interface? 

EASY 

NOMINAL 

DIFFICULT 

Complexity 

MRDB 

DIFFICULT 

1 

FLTMPS/EPM  COGNOS 

NOMINAL 

1 

1 

1 

CASREP  DATABASE 

NOMINAL 

1 

AREA  OF  RESPONSIBILITY  INFO 

NOMINAL 

1 

1 

1 

2  KILO  DATABASE 

EASY 

1 

SAILOR  TO  ENGINEER 

NOMINAL 

1 

1 

1 

PMS 

DIFFICULT 

1 

INTERFACE  DIAGRAMS 

NOMINAL 

1 

1 

1 

NSLC 

NOMINAL 

1 

1 

1 

NAYS  UP 

NOMINAL 

1 

MFOM 

NOMINAL 

1 

ORTSTARS 

NOMINAL 

1 

1 

1 

Sum 

1 

9 

2 

6 

Figure  81.  Interfaces  Analysis 


Requirements  Understanding 

H 

0.77 

Architecture  Understanding 

N 

Level  of  Service  Requirements 

H 

Migration  Complexity 

N 

Technology  Risk 

N 

U)0 

Documentation 

VH 

#  and  diversity  of  installation  s/platforms 

EH 

#  of  recursive  levels  in  the  design 

N 

Stakeholder  team  cohesion 

VL 

Personnel/team  capability 

N 

1  00 

Personnel  experience/continuity 

H 

0  82 

Process  capability 

N 

1  00 

Multisite  coordination 

N 

1  00 

Tool  support 

H 

O  85 

High  due  to  Classified  Content  and  iA  issue 


composite  effort  multiplier 


Figure  82.  COSYSMO  Size  Multiplier  Inputs  for  a  New  System 
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Results 


Cost  and  Schedule 
Effort  =102  Person-months 
Schedule  =  6  Months 
Cost  =  SSI  9347 

Effort  Distribution  (Person-Months) 


Phase  / 
Activity 

Conceptualize 

Develop 

Operational 
Test  and 

Evaluation 

Transition 

to 

Operation 

Acquisition 
and  Supply 

2,0 

37 

0.9 

0.6 

Technical 

Management 

3.8 

6.6 

4.4 

2.6 

System 

Design 

104 

12.3 

5.2 

2.8 

Product 

Realization 

2,0 

4.6 

4.9 

3.8 

Product 

Evaluation 

5.7 

8.6 

12.7 

4.8 

Figure  83.  Expert  COSYSMO  Output  -  ESDS+ 


Results 


Cost  and  Schedule 


Effort  =25 £  Person-months 
Schedule  =  9  Months 
Cost  =  52065008 


Effort  Distribution  (Person-Months) 


Phase  f 
Activity 

Conceptualize 

Develop 

Operational 
Test  and 

Evaluation 

Transition 

to 

Operation 

Acquisition 
and  Supply 

5.1 

9.2 

2.3 

1.4 

Technical 

Management 

97 

16.7 

11.0 

6.6 

System 

Design 

26.3 

31.0 

1 3,2 

7.0 

Product 

Realization 

5.0 

11.6 

12,4 

9.7 

Product 

Evaluation 

14.4 

21 .6 

32.0 

12,0 

Figure  84.  Expert  COSYSMO  Output  -  New  System 
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APPENDIX  D.  PROJECT  MANAGEMENT  PLAN 


This  appendix  contains  the  Project  Management  Plan  (PMP)  for  the  NPS  MSSE 
Distance  Learning  Cohort  311-1130.  The  PMP  was  prepared  by  the  NSWC  PHD 
Distance  Support  team  during  their  first  of  three  quarters  of  the  capstone  project.  This 
document  identifies  and  outlines  the  plan  the  Distance  Support  team  used  to  conduct  this 
research  project.  The  team  used  the  PMP  to  define  project  goals  and  objectives,  plan  and 
organize  the  effort  and  resources  needed  to  accomplish  the  tasks  necessary  to  complete 
the  project,  establish  a  system  engineering  approach,  and  to  specify  timelines  for 
completion.  The  PMP  was  approved  and  signed  by  the  Chair  of  the  Department  of 
Systems  Engineering,  Dr.  Clifford  Whitcomb  on  September  4,  2012. 

It  is  important  to  note  that  there  have  been  a  few  modifications  to  the  project  plan 
since  the  PMP  was  signed  and  approved.  For  instance,  the  systems  engineering  (SE) 
process,  shown  in  Figure  2  of  the  PMP,  and  the  SE  project  activities,  shown  in  Figure  3 
of  the  PMP,  were  both  modified  to  ensure  the  project  could  be  completed  within  the  time 
allowed.  Due  to  the  time  constraints  and  in  order  to  provide  a  more  in  depth  research 
project,  the  team  decided  to  focus  on  the  left  hand  side  of  the  V-shaped  SE  model  shown 
in  Figure  2.  The  capstone  team  worked  with  and  obtained  approval  from  the  stakeholders 
and  project  advisors  to  make  the  Stakeholder  Requirements  Definition,  Requirements 
Analysis  and  Architecture  Design  technical  processes  the  focal  points  of  the  project.  The 
updated  SE  model  can  be  seen  in  Figure  4  of  the  capstone  report.  In  terms  of  the  SE 
project  activities,  shown  in  Figure  3  of  the  PMP,  the  team  worked  with  the  stakeholders 
and  advisors  to  modify  and  focus  on  a  portion  of  the  activities.  The  team  completed 
Activity  1.0,  Define  Stakeholder  Needs,  and  its  sub-activities,  Activity  2.0,  Requirements 
Analysis,  and  its  sub-activities,  and  Activity  3.0,  System  Architecture  Design,  and  its 
sub-activities.  The  updated  SE  project  activities  can  be  seen  in  Figure  5  of  the  capstone 
report. 
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Acronym 
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T&E 

Test  &  Evaluation 

TOC 

Total  Ownership  Cost 

TYCOM 

USN  Type  Command 
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USN 

WBS 


United  States  Navy 
Work  Breakdown  Structure 


L  INTRODUCTION  &  PROJECT  OVERVIEW 


Ill  is  is  the  capstone  Project  Management  Plan  (PMP)  for  the  Naval  Postgraduate 
School  (NPS)  Masters  of  Science  in  Systems  Engineering  (MSSE)  distance  learning 
cohort  311-11 30.  This  project  management  plan  lays  out  the  organizational  and 
technical  approaches  the  team  will  use  during  the  course  of  the  project.  Specifically,  the 
PMP  describes  the  specific  problem  or  issue  that  the  project  will  address,  the  project 
objectives,  llie  systems  engineering  approach,  the  technical  and  programmatic  activities 
planned,  and  the  team's  organization.  It  will  also  present  the  project  schedule  with  major 
milestones  and  deliverables  (NFS  2006). 

A.  BACKGROUND 

Requirements  of  homeland  defense*  national  security,  and  the  war  on  terrorism 
have  made  a  ship's  mission  more  critical  than  ever  (Office  of  Homeland  Security  2002). 
When  equipment  fails  there  is  little  time  to  wait  tor  engineers  or  technicians  to  fly  to  the 
deployed  ship  to  help  resolve  the  problem.  By  h ringing  leading- edge  distance  support 
technology  to  our  sailors  at  sea,  twenty  four  hours  a  day,  seven  days  a  week,  the 
engineers,  logisticians,  and  technicians  of  Naval  Surface  Warfare  Center,  Port  Huencme 
Division  (NSWC  PHD)  are  working  to  help  our  ships  return  to  operational  readiness 
without  leaving  their  positions.  Distance  support  is  important  due  to  (Camanag  2012): 

*  Reduced- Manned  Ships  (such  as  the  Littoral  Combat  Ship  [LCS]) 

*  Increasing  complexity  of  systems  due  to  technology  advancements, 
integration  of  emergent  capabilities,  and  Foreign  combat  system  elements 

*  Pressures  to  reduce  Total  Ownership  Cost  (TOC) 

Current  distance  support  is  often  slow  and  ineffective.  Numerous  distance 
support  tools  exist  but  need  to  be  consolidated  and  or  integrated  more  effectively.  In 
addition,  distance  support  activities  <ire  often  not  captured  for  knowledge  retention  and 
reutilization.  Knowledge  that  is  captured  is  difficult  to  access  and  utilize  in  a  timely 
manner.  Better  tools  need  to  be  developed  to  allow  knowledge  to  be  captured  and 
utilized  when  needed  to  help  improve  distance  support  and  ultimately  fleet  readiness. 
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Tliis  capstone  team  will  investigate  the  requirements  and  parameters  needed  to 
provide  a  technically  feasible,  cost  effective,  and  efficient  approach  for  N$WC  PHD  to 
provide  distance  support  to  the  United  States  Navy  (IJSN).  lliis  project  will  investigate 
improvement  options  for  providing  distance  support  to  the  fleet.  In  addition  to  helping 
the  fleet,  it  will  benefit  the  command,  NSWC  PHD,  which  all  team  members  represent. 

B,  PROBLEM  STATEMENT 

1.  Initial  Problem  Statement 

When  this  capstone  project  was  started,  the  initial  problem  statement  was:  A 
decline  in  sailors'  ability  to  operate,  maintain,  and  sustain  combat  systems  necessitates 
the  need  to  optimize  distance  support  from  Fleet  field  support  activities  to  meet  current 
and  future  Fleet  Readiness  demands  (SEA  21  2010),  As  new  surface  ship  programs 
emerge,  the  complexity  of  combat  systems  has  increased.  In  recent  years,  the  Navy  has 
identified  reducing  manning  levels  as  a  key  approach  to  reduce  costs.  The  Navy’s 
decision  lo  reduce  manning  dropped  the  Fleet's  availability  levels  to  “below  the  levels 
required  to  support  material  readiness  requirements”  (Balisle  2010).  Inadequate  distance 
support  results  in  reduced  fleet  readiness,  increases  shore  activity  and  Subject  Matter 
Expert  (SME)  manpower  requirements,  decreases  fleet  independence,  decreases 
efficiencies,  and  increases  total  ownership  costs. 

After  further  investigation  and  research,  the  team  discovered  that  fleet  distance 
support  covers  a  wide  area  of  ships  operation  and  maintenance.  The  Commander  of 
Naval  Surface  Forces  (CNSF)  defines  distance  support  as:  “Distance  support  is  a  Navy 
Enterprise  effort  that  combines  people,  processes,  and  technology  into  a  collaborative 
infrastructure  without  regard  to  geographic  location/"  and  “distance  support  projects 
reactive,  proactive,  and  predictive  support  to  sailors  across  functional  areas  in  order  to 
achieve  the  right  readiness  at  the  right  time,  at  the  right  cost'1  (CNSF  2010). 

The  CNSF  categorizes  distance  support  by  the  following  four  functional  areas: 

*  logistics 

*  Maintenance  and  Modernization 

*  Manpower,  Personnel,  Training  and  Education  (MPT&E) 

2 


227 


*  War  fighting 

In  addition,  each  of  the  four  categories  listed  above  also  have  many  sub  functions 
and  unique  processes.  Hie  magnitude  and  volume  of  fleet  distance  support  activities  that 
occur  across  these  functional  areas  is  enormous,  The  team  soon  realized  that  a  capstone 
project  that  improves  fleet  distance  support  across  all  four  functional  areas  is  beyond  our 
ability  given  the  limited  resources  and  time  to  complete  the  project.  The  team  agreed  that 
the  project  had  to  bo  scoped  to  a  manageable  level,  so  it  was  re -focused  to  the  distance 
support  areas  that  NSWC  PHD  currently  supports.  NSWC  PHD  is  primarily  involved  in 
limited  aspects  of  logistics,  maintenance,  and  modernization  of  combat  systems  installed 
on  surface  ships.  Since  most  of  the  team’s  work  is  related  to  maintenance,  the  team 
limited  the  scope  to  maintenance  functions. 

2,  Reused  Pujblein  Statement 

NSWC  PHD  has  several  methods  for  conducting  distance  support  for  ship 
maintenance.  NSWC  PHITs  capabilities  include  both  remote  systems  monitoring  and 
technical  assistance  (tech  assist),  Both  services  are  provided  in  real  time,  near  real  time, 
and  oil  a  periodic  basis.  Each  of  these  levels  of  distance  support  has  unique  processes 
and  requirements  which  again  would  require  significant  investigation  and  research. 

Since  time  was  of  the  essence,  the  team  decided  to  seek  guidance  from  several 
stakeholders  to  help  scope  the  project.  After  meeting  with  several  key  stakeholders  at 
NSWC  PHD,  the  team  decided  to  focus  on  improving  distance  support  knowledge 
capturing  and  knowledge  reutilization  primarily  because  a  solution  was  needed  to 
aggregate  data  from  multiple  distance  support  data  collection  sources.  The  stakeholders 
advised  that  they  were  specilically  interested  in  capturing  and  maximizing  the  reuse 
potential  of  distance  support  activities  and  experiences  to  increase  Heel  self-help  and 
improve  equipment  reliability  thru  design  changes  and  new  manufacture  of  combat 
systems. 

Therefore,  with  the  stakeholder  preferences  in  mind,  the  team  revised  the  problem 
statement  as  follows: 
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NSWC  PHD  needs  to  improve  distance  support  knowledge  capturing  in  order  lo 
^utilize  this  knowledge  to  provide  more  effective  distance  support  capability  to 
the  Heel  and  perform  more  effective  trend  analysis  to  improve  equipment 
reliability  utilizing  existing  shore  support  resources  and  processes  (Scheid  et  al 
2G12)r 

C.  PROJECT  SC  OPE 

The  team  lias  scoped  the  project  to  focus  on  the  area  of  improving  distance 
support  knowledge  capturing  and  reutilization,  as  it  applies  to  NSWC  PHD.  The  team 
will  apply  a  system  engineering  approach  and  techniques  to  clearly  define  the  problem, 
del i ne  and  prioritize  stakeholder  requirements,  determine  the  measures  of  effectiveness 
perform  a  functional  analysis,  research  and  compare  possible  solutions,  and  develop 
conclusions  and  recommendations. 

As  the  revised  problem  statement  suggests,  the  learn  will  focus  on  finding  a 
solution  to  determine  what  methods  and  lools  are  needed  to  allow  distance  support 
knowledge  and  experience  to  he  captured  and  utilized  to  help  improve  distance  support 
and  ultimately  fleet  readiness,  llierefore,  the  team  will  focus  primarily  on  developing  a 
solution  that  will  aggregate  data  from  numerous  existing  distance  support  sources  and 
export  data  lo  the  fleet  lo  promote  self-help  and  export  data  to  help  facilitate  trend/failure 
analysis  opportunities. 

Below  is  a  list  of  initial  research  questions  that  will  be  pursued  for  I  his  capstone 

project: 

•  What  are  the  specific  fleet  needs  for  distance  support? 

■  What  tools  and  processes  currently  exist? 

•  What  technology  is  available  to  modernize  and  evolve  distance  support 
capabilities? 

•  What  methods/approaches  have  other  organizations  successfully 
implemented? 

•  What  tools/technology  have  other  organization  successfully  utilized? 
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Expected  deliverables  include  a  formal  system  engineering  report  and  presentation. 
The  team  will  also  provide  recommendations  for  implementing  solutions  that  will  meet 
stakeholder  expectations.  Resources,  at  a  minimum,  will  include  existing  distance 
support  processes  and  tools,  past  distance  support  studies,  and  interviews  from  personnel 
currently  responsible  for  managing  and  conducting  distance  support. 

IX  PROJECT  OBJECTIVES,  CONSTRAINTS,  &  ASSUMPTIONS 

Ihere  are  two  main  academic  objectives  of  the  capstone  project.  The  first  is  to 
apply  the  system  engineering  knowledge,  skills,  and  techniques  acquired  in  the  NPS 
MSSE  curriculum  to  solve  an  applicable  real  world  problem.  The  second  is  to 
successfully  complete  the  capstone  project,  including  delivering  all  academic  and 
stakeholder  deli  verables,  within  the  given  lime  frame. 

He  low  is  a  list  of  project  constrain  Is: 

■  The  project  must  be  completed  in  3  academic  quarters. 

*  The  project  must  he  accomplished  within  the  time  and  manpower 
available. 

*  The  project  must  he  accomplished  without  incurring  any  monetary  costs. 

■  Deliverables  must  meet  NPS  guidelines. 

Below  are  the  assumptions  made  to  guide  the  project: 

*  Hi  ere  is  significant  benefit  to  improving  distance  support  knowledge 
capturing  and  reutilization, 

*  [here  are  better  methods  and/or  better  tools  for  capturing  and  re  utilizing 
distance  support  knowledge. 

*  Demand  for  distance  support  will  increase  or  remain  constant. 

*  Regional  Maintenance  Centers  (RMC)  and/or  In  Service  Engineering 
Agents  (ISEA)  technical  expertise  is  stable. 

*  RMCs/ISEAs  arc  committed  to  distance  support  knowledge  capturing  and 
re  utilization. 
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ORGANIZATION  STRUCTURE  WITH  ROLES  &  RESPONSIBILITIES 


The  team  is  organized  by  competency  areas  to  support  the  capstone  project,  as 
shown  in  Figure  1. 


Fig  u  re  I,  Organ  izal  ion  Chart  (After  Kerzner  201 1 ) 
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1. 


NFS  Advisors 


Advisors  shall  guide  students  in  the  formulation  of  project  topics,  guide  students 
in  the  development  of  the  PMP  and  the  Capstone  Project  Report,  help  identify  project 
sponsors  when  appropriate,  help  lay  out  a  schedule  of  milestones,  monitor  the  students' 
progress,  provide  consultation  and  direction,  and  review  documents  for  accuracy  and 
completeness  and  products  which  result  from  the  project  (NFS  2006). 

2,  Technical  Roles 

The  systems  engineering  product  development  responsibilities,  as  shown  in 
Figure  1 ,  show  which  product  areas  each  team  member  is  responsible  for  during  the 
project  development.  lire  product  development  responsibilities  are  divided  into  six 
system  engineering  principals:  requirements  engineering,  architecture  design,  software 
design,  integration  and  testing,  cost  analysis,  and  risk  management 

•  Requirements  Engineering  -  Responsible  for  the  iterative  elicitation, 
elaboration,  verification,  and  documentation,  and  evaluation  of  all 
capstone  project  requirements. 

•  Architecture  Design  -  Responsible  for  the  development  and  design  of  the 
system  architecture.  Creates  the  Dq-^rt  merit  of  Defense  Architecture 
Framework  (DoDAF)  views  arid  documents  the  architecture  artifacts. 
Translates  stakeholder  needs  and  objectives  into  system  functional 
requirements  and  decomposes  these  requirements  into  functional 
architecture.  Performs  functional  arid  gap  analysis  to  determine  which 
data  and  software  tools  that  are  required  to  he  integrated  into  the  data 
aggregation  system.  An  Analysis  of  Alternatives  (AoA)  will  also  be 
conducted  to  detenu ine  the  alternate  solutions  for  the  data  aggregation 
system  based  on  the  cost  analysis  and  performance  effectiveness  of  each 
alternative  system. 

■  Software  Design  -  I>evelops  or  improves  existing  software  tool  that  will 
aggregate  data  from  numerous  existing  distance  support  sources  and 
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export  data  to  the  fleet  lo  promote  self-help  and  export  data  lo  other  tools 
to  help  facilitate  trend/failure  analysis  opportunities. 

*  Integration  &  Testing  -  Responsible  for  conducting  any  necessary  system 
integration  and  testing  that  may  occur  during  Modeling  &  Simulation 
(M&S)  to  make  sure  the  system  performance  meets  its  requirements  based 
on  Key  Performance  Parameters  (KPP).  Integration  and  testing  may  also 
occur  during  the  design  and  implementation  of  the  selected  architecture, 

*  Cost  Analysis  -  Responsible  For  all  cost  related  analyses,  including 
conducting  a  Business  Case  Analysis  (BCA)  and  provides  Return  or 
Investment  (ROI)  estimation. 

*  Risk  Management  -  Responsible  for  conducting  risk  management, 
performs  risk  assessment  and  provides  risk  mitigation. 

3,  Administrative  Roles 

'Flie  project  management  responsibilities,  as  depicted  in  Figure  1,  show  which 
overarching  tasks  each  team  member  is  responsible  for  during  the  project  development. 
The  project  management  responsibilities  are  divided  into  five  categories:  project  lead. 
Work  Breakdown  Structure  (WBS)  lead.  Configuration  Management  (CM)  lead, 
technical  editor  (Tech.  Editor),  Systems  Engineering  (SE)  and  I  lu man  Systems 
Integration  (FIS  I),  and  Administration  (Admin). 

*  Project  Lead  -  Acts  as  the  overall  visionary  and  monitors  the  progress 
toward  meeting  capstone  project  objectives.  The  project  lead  is 
responsible  for  managing  and  executing  the  project  according  lo  the 
project  plan  and  to  maintain  a  balance  between  tire  technical,  schedule, 
and  administrative  requirements  of  the  pmjeet  and  die  organization  of 
team  efforts.  The  project  leader's  responsibilities  include:  facilitate  team 
meetings  and  information  exchange,  monitor  and  guide  the  overall  project 
activities,  foster  team  member  participation,  mid  promote  collaboration 
among  the  team  members. 

*  WBS  Lead  -  Responsible  for  creating,  tracking  and  monitoring  the  WBS 
through  the  project  term. 
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CM  Ijead  -  Responsible  for  ensuring  all  products  created  by  the  group 
follow  a  proper  change  process  to  ensure  consistency  in  review  and 
certainty  of  content. 

Technical  Editor  -  Ensures  all  the  technical  reports  and  publications 
generated  by  the  team  will  meet  the  style  guide  and  well  written. 

SE  &  HSI  Lead  -  Verifies  that  sound  systems  engineering  principles, 
techniques  mid  theory  jure  utilized  in  all  tasks  associated  with  the  project. 
Also  responsible  for  ensuring  human  factors  are  considered  during  the 
proj  ect. 

Administration  -  Responsible  for  taking  notes  during  team  meeting  and 
keeping  track  of  action  items,  keeping  minutes  of  meetings,  assembling 
drafts,  consol idaling  inputs  to  all  project  documents,  and  managing  the 
data  repository. 


STAKEHOLDERS 


F, 

A  list  of  potential  stakeholders  and  the  team’s  best  estimate  of  their  primary 
concern  with  regards  to  this  project  is  given  in  Table  1  below. 


Stakeholder 

Primary  Concern 

Fleet 

Improve  fleet  readiness,  redueo  TOC 

Waterfront  Activities 

Improve  distance  support  capabilities,  capture 

knowledge 

USN  Type  Commander  (TYCOM) 

Improve  fleet  readiness*  DS  effectiveness.  System 

Performance  Metrics 

Naval  Sea  Systems  Command 

(NAVSEA) 

Improve  distance  support  capabilities,  reduce  Life 
Cycle  Cost  (LCC) .  System  Performance  Metrics. 

Failure  Trends 

Naval  Surface  Warfare  Center,  Pori 

Ilueneme  Division  (NSWC  PHD) 

Improve  fleet  readiness,  improve  distance  support 
capabilities,  capture  knowledge,  and  reduce 

LCC/TOC 

Program  Executive  Office  (PFO) 

Improve  distance  support  and  reduce  TOC,  Failure 

Trends,  Acquisition  Impacts 

Office  of  the  Chief  of  Naval  Operations 

(OPNAV) 

Improve  fleet  readiness  and  reduce  TOC 

Table  1.  Stakeholders 
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PROJECT  SPONSORS 


All  the  sponsors  are  from  NSWC  PHD.  The  sponsors  Tor  this  capstone  project  are 
listed  in  Table  2. 

Sponsor  Title 

M  r.  T  ini  othy  T  roske  T eelmi  c al  Direc  t  or 

CAPT  Theodore  Olson  Office  of  logistics  (OOL),  Deputy  Commander 
Mr.  Fabio  V Stale  Office  of  I  x>gi sties  (OOL).  Director 

CAPT  (Scl)  Scott  Davis  Chief  Engineer  (C HENG),  Office  of  Engineering 
Technology  (OET) 

Mr.  David  S  die  id  OET.  Knowledge  Management  and  DS  Advocate 

Mr.  David  Willi  a  ins  OET  DS  Community  of  Practice  Lead 

Ms.  t  'oral v n  Akers  Fleet  Liaison 

Mr.  John  Lester  SE  -  A  Department  l^ead 

IS  1 1'.  N oel  Ca in  a  nag  SE  -  L  Dep arlm ent  I 

Mr.  James  Childs  SE  -  S  Department  lx: ad 

Table  2,  Project  Sponsors 
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II.  SYSTEMS  ENGINEERING  APPROACH 


A.  OVERVIEW 

The  team  will  adopt  the  new  2009  DoD  SK  Model  (DAU  2011)  as  shown  in 
Figure  2  below,  as  a  framework  for  the  project  systems  engineering  process  due  to  its 
standard  applicability  to  system  engineering  projects.  The  2009  DoD  SE  Model  consists 
of  two  major  processes;  the  technical  management  processes  form  the  executive  or 
control  logic  that  steers  system  development  to  meet  project  or  phase  objectives.  The 
technical  processes  are  depicted  in  a  V-shaped  pattern.  This  pattern  portrays  the  top- 
down  design  that  occurs  iis  requirements  <ire  progressively  allocated  from  the  system 
level  down  to  lower-level  elements.  In  addition,  the  Y-shaped  model  of  the  technical 
processes  more  explicitly  shows  the  bottom  up  realization  from  lowest  level  components 
to  higher  assemblies  to  achieve  the  complete  system.  The  technical  processes  are  applied 
iteratively  and  recursively  across  the  I  lie  cycle  and  at  different  levels  m  the  system 
hierarchy  to  elaborate  and  mature  the  system. 


Implementation 


Figure  2.  2009  DoD  System  Engineering  Model  (From  DAU  2011) 
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The  learn  will  use  Hie  tailored  SE  process  as  illustrated  in  Figure  3  below  lbr 


activities  in  the  development  of  the  capstone  project. 
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Figure  3. 


SE  Process  to  Project  Activities  (Alter  DAU  201 1 ) 


If-  TECHNICAL  PROCESSES 

L  Define  Stakeholder’s  Needs 

The  llrsl  step  of  the  SE  process  is  to  conduct  interviews  with  users  and 
stakeholders  to  determine  the  needs,  requirements,  and  objectives  for  the  use  of  data 
aggregation  system  using  the  data  products  generated  from  the  shore  support 
infrastructure.  From  the  interviews,  the  learn  will  also  develop  a  Concept  of  Operations 
(CONORS), 


2,  Requirements  Analysis 

During  this  phase,  the  team  will  define  the  distance  support  functional  and 
performance  requirements,  sueh  as  the  Key  Perf  ormance  Parameters  (KPP)  of  the  system, 
based  on  the  stakeholder’s  needs  analysis.  The  team  will  then  conduct  the  research  and 
create  a  list  of  existing  DS  functions  and  systems  currently  used  in  the  fleet,  which 
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include  the  data  products  that  are  generated  from  each  function  and  system.  These 
existing  functions  will  then  he  mapped  against  the  functional  requirements  based  on 
stakeholder’s  needs  to  determine  if  there  are  any  capability  gaps. 

The  team  will  also  develop  the  test  and  evaluation  strategy  which  will  be  used  in 
the  system  verification  and  validation  phase  later  in  the  process  based  on  the  developed 
functions  and  requirements. 

3,  System  Architecture  Design 

In  this  phase,  the  team  will  develop  the  detailed  architecture  design  of’ the  system 
by  decomposing  the  functions  using  hierarchy  structure  and  publish  the  results  in 
compliance  with  the  Department  of  Defense  Architecture  Framework  (DoDAF).  Hie 
Functional  Flow  Block  Diagram  (FFBD).  which  is  a  multi-tier,  lime -sequenced,  step-by- 
step  flow  diagram  of  system’s  function  flow,  will  be  used  to  provide  an  easy-to-follow 
graphical  representation  for  illustrating  the  system  based  on  its  functional  elements,  lire 
FFBD  will  serve  as  the  System  Functionality  Description  (SV- 4a)  model.  Also,  a 
functional  allocation  matrix  will  be  created  to  accompany  the  SV-4a7  as  this  will  help  to 
map  system  functions  to  system  elements. 

Following  the  development  of  the  architecture,  the  team  w  ill  then  conduct  an 
Analysis  of  Alternatives  (AoA)  to  determine  alternate  solutions.  In  conducting  the  AoA, 
a  basic  cost  analysis  of  all  options  will  be  conducted  to  help  determine  the  most  feasible 
and  cost  effective,  Before  system  implementation,  a  more  substantial  cost  analysis  will 
also  he  performed  to  determine  the  cost  effectiveness  as  well  as  the  ROI  benefits  for 
implementing  the  chosen  alternative  system. 

4.  System  Implementation 

As  authorized  by  the  command  sponsor,  the  team  is  allowed  to  use  the  existing 
hardware  available  at  NSWC  PFID  for  system  implementation.  During  this  phase,  the 
team  will  develop  or  improve  existing  software  tools  such  as  database  and  other  analysis 
tools  which  will  be  used  for  data  aggregation  as  defined  in  the  architecture  design  phase. 
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5. 


System  Integmtinti 


In  this  phase,  the  team  will  assemble  all  the  data  and  software  modules  and 
integrate  into  the  system  in  preparation  Tor  system  verification  and  validation  phase. 
Integration  and  testing  will  occur  during  M&S  and  possibly  during  design  and 
implementation  of  the  selected  architecture,  ITie  team  will  model  candidate  solutions,  as 
applicable,  and  test  for  compatibility  and  performance.  Numerous  data  sources  currently 
exist  so  the  modeling  processes  will  attempt  to  integrate  data  from  multiple  sources  into  a 
single  system  so  that  data  can  be  collected  and  utilized  to  satisfy  requirements.  Once 
integrated,  the  system  should  be  capable  of  providing  information  that  can  be  used  to 
improve  sailor  sell-help  and  used  to  improve  equipment  reliability. 

6,  System  Verification  and  Validation 

During  this  phase  the  system  will  be  tested  against  Verification  &  Validation 
requirements  defined  in  the  requirements  analysis  phase  to  make  sure  the  products  will 
satisfy  the  stakeholder's  needs.  Any  discrepancies  and  issues  with  the  design  that 
captured  during  this  phase  will  be  debugged,  corrected,  and  rc-de signed. 

7,  Deploy 

As  desired  by  the  command  sponsor,  the  system  desired  will  be  a  common  tool 
across  all  NSWC  PHD  supported  systems.  These  systems  include  combat  systems  (e.g. 
AEGIS),  weapons  (e  g.  MK  38  Machine  Gun  System  (MGS)},  radars  (e  g.  SPQ-9B 
radar),  Hull  Mechanical  and  Engineering  (HM&E)  systems  (e.g.  MK  41  Vertical  Launch 
System  (VLS)),  equipment  groups  (e  g.  switchboards),  other  systems  (e,g.  Collaborative 
Engagement  Capability  (e.g.  CEC)).  and  Force  protection  (e.g  Acoustic  Hailing  Device). 
With  many  systems  under  consideration,  the  plan  is  to  select  a  specific  system  from 
which  to  perform  a  beta  test.  A  community  of  stakeholders  w  ill  be  solicited  to  be  a  part 
of  the  lest,  which  is  expected  to  provide  feedback  such  as  user  interface  to  overall  logic 
and  usefulness.  Upon  satisfactory  completion  by  the  command  sponsors,  the  feedback 
w  ill  be  adjudicated,  and  the  product  will  evolve  to  include  all  the  systems  under  NSWC 
PHD  purview. 
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TECHNICAL  MANAGEMENT  PROCESSES 


C. 

The  capstone  project  requires  management  in  several  areas  of  concern. 
Management  is  required  to  ensure  the  end  product  is  completed  on  schedule  and  to  the 
satisfaction  of  stakeholders  and  NFS.  These  areas  of  concern  are  project  risks, 
configuration,  and  information  assurance. 

1.  Risk  Management 

Risks  to  this  project  will  primarily  he  managed  in  accordance  with  the  Risk 
Management  Guide  for  DoD  Acquisition  (DoD  2006).  Although  written  in  general 
terms,  It  will  he  tailored  to  this  project.  Figure  4  describes  the  process  promulgated  in  the 
guide:  It  is  important  to  note  the  focus  on  mitigation  or  control  aspect  Project 
management  can  also  use  acceptance,  avoidance  and  transfer  strategies  lo  respond  to 
risks  (Kerzer  2009.  784). 


Rtsk 

Mitigation 

Plan  Implementation 


Figure  4,  Risk  Management  Process  (From  DoD  2006) 
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Reporting  each  ri  sk  1  dentifi  ed  will  be  performed  through  th  e  use  of  a  risk  m  atrix 
shown  in  Figure  5  below,  which  classifies  each  risk  by  likelihood  and  consequence. 
When  project  risks  need  to  be  conveyed  to  capstone  professors  or  stakeholders,  this 
reporting  matrix  will  be  used. 


Consequence 


Figure  5. 


Risk  Assignment  Matrix  (From  D oD  2006) 


The  consequence  for  a  risk  will  be  determined  by  using  Table  3  below. 


Level 

Schedule 

1 

Minimal  or  no  impact 

2 

Able  to  meet  key  dates 

Slip  <  1  week 

3 

Minor  schedule  slip.  Able  to  meet 

key  milestones  with  no  schedule  float 

Slip  <  2.5  weeks 

4 

Program  critical  path  affected 

Slip  <  1  month 

5 

Cannot  meet  key  program  milestones 

Slip  >  1  month 

Table  3. Risk  C  onsequence  Classification  (After  D  oD  2006) 
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The  likelihood  of  each  risk  will  be  determined  by  using  Table  4  below. 


Level 

Likelihood 

Ih'abahdity  of  Occurrence 

1 

Not  Likely 

<10% 

2 

Low  likelihood 

<30% 

3 

Likely 

<50% 

4 

Highly  likely 

<90% 

5 

Near  Certain 

<100% 

Tuhlc  4  Risk  Likelihood  Classification  (After  DoD  2006) 


Response  to  risk  by  controlling,  transferring  or  avoidance  will  be  designed  to 
lower  probability,  severity  or  both.  This  would  be  reflected  in  a  new  risk  matrix  that 
could  move  risks  in  the  "red"  boxes  to  "yellow"  or  "green".  The  last  option,  acceptance, 
will  not  change  the  risk  matrix;  it  is  used  for  a  risk  that  is  tracked  but  no  course  of  action 
is  developed  until  occurrence  happens. 

2.  ('on figuration  Management 

The  team  will  use  Dropbox™  ( \v wvv. dro nbox. com )  and  Sakai®  as  archive  tools 
throughout  the  project.  The  deliverables  will  be  in  the  form  of  Microsoft  (MS)  Word® 
documents,  MS  Excel®  spreadsheets,  MS  Power  Point®  presentations,  drawings,  and 
architecture  artifacts  dc vc loped  in  CORE®.  The  revision  process  will  be  tracked  using 
the  file  name  with  an  incremented  alpha  numeric  number  with  the  team  member's  initial 
(Le.,  PMl1  Draft  Rev  A  HT).  Once  a  deliverable  is  ready  for  submission  it  will  be 
published  using  numeric  revisions  (i.e.,  PMP  Rev  1 ).  The  numeric  revision  number  will 
be  incremented  upon  subsequent  submissions  (i.e.,  PMP  Rev  2).  All  revisions  will  be 
maintained  chronologically  in  an  archive.  Ill  is  archive  will  he  maintained  by  the 
technical  editor. 
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RESOURCES 


To  assist  in  this  project,  a  number  of  software  toots  will  be  utilized,  which  include 
but  are  not  limited  to: 

•  System  Architecture  {CORE©) 

•  Data  Storage  (Dropbox) 

•  Research  (Dudley  Knox  Library) 

•  Database  Development  (SQL  Server©) 

•  Statistical  Analysis  (MATLAB®) 

•  Modeling  &  Simulation  tools  (Extend Sim©) 

•  Microsoft®  (MS)  Office  Suite  (Word®,  Excel©.,  Power  Point©.  Outlook©. 
Project®,  and  Access®) 

•  NPS  Thesis  Project  Office  Website 

•  Sakai® 
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m.  MILESTONES  AND  DELIVERABLES 


fhe  milestones  associated  with  the  capstone  project  are  listed  in  t  able  5  below. 
Every  milestone  represents  an  important  achievement  in  the  capstone  project.  Through 
each  of  the  listed  milestones,  the  team  will  show  progress  and  advancement  with  the  goal 
of  completing  all  listed  deliverables  within  the  given  timeframe.  The  capstone  Project 
will  span  for  three  academic  quarters.  At  the  end  of  each  quarter,  the  learn  will  use  an  In- 
Process  Review  (IPR)  as  a  forum  to  brief  NPS  faculty  and  stakeholders  on  the  project’s 
status  and  progress  and  to  present  deliverables  completed  up  to  lhal  point  in  time. 

At  the  end  of  the  first  academic  quarter,  the  team  will  present  an  overall  view  of 
the  project,  using  the  PMP  as  a  reference,  during  the  first  IPR.  The  products  included  in 
the  PMP  will  be  used  to  present  the  projects  scope  and  objectives,  team’s  organization, 
systems  engineering  process,  and  technical  and  programmatic  activities  planned  to 
successfully  complete  all  listed  deliverables.  Furthermore,  the  team  will  present  a 
comprehensive  stakeholder  need  analysis;  including  a  detailed  explanation  of  the  process 
taken  to  determine  needs,  requirements,  and  objectives  from  stakeholders.  Additionally, 
a  detailed  requirements  analysis  will  be  presented  to  show  how  the  team  used  the 
stakeholder  needs  to  translate  them  into  specific  functional  and  performance  requirements 
as  part  of  the  requirement  analysis.  Finally,  a  gap  analysis  wi  II  be  completed  and 
presented  during  the  first  IPR. 

The  plan  is  for  the  team  to  complete  the  system  architecture  design  by  the  end  of 
the  second  academic  quarter.  The  architecture  design  will  be  presented  using  DoDAF 
artifacts  during  the  second  IPR.  Additionally,  tire  team  will  complete  and  present  an 
analysis  of  alternatives,  cost  analysis,  and  risk  management  plan  to  NPS  faculty  and 
stakeholders.  Moreover,  M&S  will  be  completed  by  the  team  and  results  will  be 
presented  during  the  second  IPR. 

During  the  final  third  portion  of  the  project,  the  team  will  develop  or  improve 
existing  software  systems  based  on  the  system  architecture  design.  Furthermore,  the 
team  will  perform  system  integration  in  preparation  for  the  system  validation  and 
verification  phase.  The  validation  and  verification  phase  will  be  then  completed  to 
ensure  the  system  was  built  right  and  to  verify  the  right  system  was  developed.  Once  the 

21 


246 


validation  and  verification  phase  is  completed,  a  system  prototype  will  be  ready  to 
present  to  NPS  faculty  and  stakeholders.  All  completed  deliverables,  products,  and 
artifacts  developed  up  to  this  point  will  be  included  in  the  final  capstone  project  report 
and  will  be  presented  during  the  final  IPR. 


Milestones 

Deliverables 

Completion  Date 

Final  Project  Management 

Plan  Due 

Project  Management  Plan 

09  August  2012 

In-Process  Review  No,  1 

Stakeholder  Need  Definition  and 

Requirements  Analysis 

13  September  2012 

In-Process  Review  No.  2 

System  Architecture  Design 

(DoDAF  Artifacts),  Analysis  of 

Alternatives,  Modeling  and 

Simulation,  and  Risk 

Management  Plan 

06  December  2012 

Final  Report  Due  to  Advisors 

Draft  Capstone  Project  Report 

14  February  2013 

Final  Report  Due  to  Thesis 

Processing  Office 

Final  Capstone  Project  Report 

28  February  2013 

Final  In-Process  Review 

System  Prototype  and  Final 

Capstone  Project  Presentation 

1 4  March  2013 

Final  Report  Due  to 

Department  Chair 

Final  Capstone  Project  Report 

15  March  201 3 

Table  5,  Milestones  and  Deliverables 


The  preliminary  schedule  of  major  events  for  this  capstone  project  is  depicted  in 
Figure  6.  The  schedule  also  captures  the  initial  deliverables  as  outlined  in  the  Capstone 
Project  Guide  (NSP  2006),  The  schedule  will  he  further  developed  throughout  the 
duration  of  the  project  and  each  of  the  major  events  will  be  broken  down  to  show 
additional  detail  for  each  of  the  tasks  required  to  complete  all  deliverables. 
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ID 

. 

Task  tome 

Duration  part  pnfsh 

Predec 

1 

Distance  Support  Casptone  Project 

ISO  days  Mon  7/16/12  Fri  3/22/13 

2 

✓ 

Initiate  Project 

17  days  Mon  7/16/12  Tue  8/7/12 

7 

Status  Update  (Sign  143  on  Sakai) 

95  days  Thu  7/19/12  Thu  11/29/12 

27 

PMP  Development 

IS  days  Mon  7/16/12  Thu  8/9/12 

33 

Stakeholder  Requirements  Definition 

145  days  Mon  7/16/12  Fri  2/1/13 

34 

Identify  Stakcholdcr(s) 

5  days  Mon  7/16/12  Fri  7/20/12 

35 

Define  Stakeholder  Needs 

5  days  Mon  7/23/12  Fri  7/27/12 

34 

36 

Conduct  Stakeholder  Surveys 

10  days  IVbn  7/30/12  Fri  8/10/12 

35 

37 

Categorize  Survey  Data 

10  days  Mon  8/13/12  Fri  8/24/12 

36 

38 

Develop  System  GONOPS 

10  days  IVbn  1/21/13  Fri  2/1/13 

78 

39 

Requirements  Analysis 

45  days  Mon  8/27/12  Fri  10/26/12 

40 

Define  DS  Functional  Requirements 

10  days  Mon  8/27/12  Fri  9/7/12 

37 

41 

Define  Performance  Requirements 

10  days  Mon  9/10/12  Fri  9/21/12 

40 

42 

Create  List  of  Existing  DS  Systems 

15  days  Mon  9/24/12  Fri  10/12/12 

41 

43 

Conduct  Gap  Analysis 

10  days  Mon  10/15/12  Fri  10/26/12 

42 

44 

■ 

Develop  T&E  Strategy 

10  days  Mon  9/3/12  Fri  9/14/12 

45 

IPR#1 

10  days  Fri  8/31/12  Thu  9/13/12 

48 

System  Architecture  &  Design 

90 days  Mon 7/23/12  Frill/23/12 

49 

Develop  System  Architecture  Using  DoDAF 

45  days  Mon  7/23/12  Fri  9/21/12 

66 

Conduct  AoA 

20 days  Mon  10/29/12  Frill/23/12 

43 

67 

■ 

Perform  Cost  Analysis 

10 days  Mon  10/29/12  Frill/9/12 

68 

Risk  IVfenagement 

20 days  Mon  10/29/12  Frill/23/12 

71 

Perform  IVbdeling  and  Simulation 

15  days  Mon  9/17/12  Fri  10/5/12 

44 

72 

IPR#2 

10  days  Thu  11/22/12  Thu  12/6/12 

75 

System  Development  &  Implementation 

20  days  Mon  11/26/12  Fri  12/21/12 

76 

Build  and  Develop  the  System 

20  days  Mon  11/26/12  Fri  12/21/12 

48,6 

77 

System  Integration 

20  days  Mon  12/24/12  Fri  1/18/13 

78 

1  ntqgrate  all  Data/Modules  into  the  System 

20  days  Mon  12/24/12  Fri  1/18/13 

76 

79 

System  Verification  and  Validation 

20  days  Mon  2/4/13  Fri  3/1/13 

80 

Verify  and  Validate  System  to  Meet  KPP 

10  days  Mon  2/4/13  Fri  2/15/13 

38 

81 

Debug  and  1  improve  the  System 

10  days  Mon  2/18/13  Fri  3/1/13 

80 

82 

Deploy 

10  days  Mon  3/4/13  Fri  3/15/13 

83 

Demostrate  System  Capability 

10  days  Mon  3/4/13  Fri  3/15/13 

81 

84 

Final  IPR 

25  days  Thu  2/7/13  Thu  3/14/13 

88 

Casptone  Report 

180  days  Mon  7/16/12  Fri  3/22/13 

Figure  6.  Schedule 
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